FreeBSD Foundation Flounders on 15 with Rust, pkgbase, and KDE

cracauer@ said:
The question is whether there will still be a `make install` after compilation, or whether you have to go through making packages and installing those.
Click to expand...
What happens when one builds and installs a port from source? Doesn't that currently make the port package and then effectively pkg install it?

If the kernel/userland base "build from source" automatically created packages at the end of make buildworld and then a make install step automatically invokes the pkg command instead of roughly copying from the source/build tree to the running system, what is the problem?

make buildkernel && make installkernel && make buildworld && make installworld, as long as it does the correct operation, does it matter if the build artifacts have been lumped together in one or more archive formats (packages)?

Is that fact really enough to stop using FreeBSD?
To me that sounds like "I'm not buying a Ford anymore because they dropped the purple velvet interior"
 
mer I don't want to use a system that now contains one of the main ressons I got away from Linux. I am predicting this will drastically lower stability on update, cause fragmentation, and make it impossible to uninstall all 3rd party software without nuking the system (which it already does, discussion on the mailing lists, they shrugged it off [you can always reinstall/whycare/insertotherbadargument etc.])
 
mer said:
What happens when one builds and installs a port from source? Doesn't that currently make the port package and then effectively pkg install it?
Click to expand...

Yes.

If the kernel/userland base "build from source" automatically created packages at the end of make buildworld and then a make install step automatically invokes the pkg command instead of roughly copying from the source/build tree to the running system, what is the problem?
Click to expand...

I'm not saying it is a problem. I am just declaring that I don't know.

I will say, though, that imagine you are working on a patch for make(1). You modify one source file. You compile and link, you have your binary. It would be nice to place that binary in the normal system position really quick (as it is right now, just a copy and chmod) and not be forced to go through a package build and package install 100 times on the same day.
 
Let me bring forward this piece that I wrote:
medium.com

Software development at 1 Hz

People keep saying that a one line source code change should take one second to be “effective”. “Effective” meaning that you get some form…
medium.com medium.com

The turnaround between changing a line of code and being able to test that line of code should be short enough so that none of your shortest term memory drops on the floor. Of course you won't be beating Lisp here, but still a C program's 1-line change can be handled in this timeframe.

I would hate for a package building and installing turnaround to wreck this.
 
cracauer@ said:
Yes.



I'm not saying it is a problem. I am just declaring that I don't know.

I will say, though, that imagine you are working on a patch for make(1). You modify one source file. You compile and link, you have your binary. It would be nice to place that binary in the normal system position really quick (as it is right now, just a copy and chmod) and not be forced to go through a package build and package install 100 times on the same day.
Click to expand...
Valid scenario, especially in the kmod area, but I fail to see why one would not be able to compile, link, copy and chmod with pkgbase. The way it appears to me is the packaging part would take place as part of or a dependency of the make install, not of the make build.

But has anyone directly asked the pkgbase team these questions? Not just posited them here, but directly ask the ones developing or one the appropriate email list(s)?

RetroComputingCollector #530 valid concerns but perhaps there are ways around it?
pkg can lock packages, we now have the FreeBSD-kmods repos, it sounded like pkgbase was adding another FreeBSD-something, so perhaps instead of locking a specific package version, one can "lock a repo"? Then thngs can be added so that doing pkg-static upgrade -f explicitly ignores pkgbase, and a user would need to specify the FreeBSD-pkbase repo.

To me that seems like a reasonable way of handling it:
Force the user to specify the pkgbase repo, otherwise default to normal "ports plus kmods".

Besides, it sounds like pkgbase is optional for 15.0 at least, so there needs to be overlapping freebsd-update and pkgbase stuff.
 
mer There is already a flag to prevent pkgbase packages from being screwed up, but according to what I learned on my mailing list and github conversation, it is only applied to 2 libraries and nothing else.
 
RetroComputingCollector said:
mer I don't want to use a system that now contains one of the main ressons I got away from Linux. I am predicting this will drastically lower stability on update, cause fragmentation, and make it impossible to uninstall all 3rd party software without nuking the system (which it already does, discussion on the mailing lists, they shrugged it off [you can always reinstall/whycare/insertotherbadargument etc.])
Click to expand...
Not a Linux user for many reasons, however, before this goes live, there should be a set of betas and release candidates, during which you can see how it works. You can add your feedback there with actual knowledge of the issues. You may decide you hate it and cannot live with it, or it may be fine. I am not convinced that panicking buys anything.
 
RetroComputingCollector said:
mer There is already a flag to prevent pkgbase packages from being screwed up, but according to what I learned on my mailing list and github conversation, it is only applied to 2 libraries and nothing else.
Click to expand...
Well, that could be a start, but that is not what I was talking about.
pkg upgrade without specifying a repo should only work on packages(ports) what's in FreeBSD repo even if you do -f; that matches current behavior

Right now people do freebsd-update fetch && freebsd-update && freebsd-update install && reboot && freebsd-update install && pkg upgrade -f. Fetch updates, install the kernel, reboot, install userland, upgrade packages.

Perhaps the pkgbase equivalent would be:
pkg upgrade pkgbase && pkg upgrade kmods && pkg upgrade

I'm failing to see a need for drama at this point in time. How about just discuss technical merits, point out possible implementation pain points, see if there are workarounds, document the heck out of everything.

The biggest issue to me is coherency. pkgbase repo must not show upgrades until ALL physical machines have been updated to the latest packages, kmods repos that depend on new versions of pkgbase must not show updates available until all machines have been updated.
That is a scheduling issue to me not a sky is falling event.

The biggest problem with packages on FreeBSD in general is jumping the gun.
How many threads here are because people have upgraded to Quarterly just as it's announced and then run into problems because of build failures?
pkgbase infrastructure needs to address that; it's basically don't show it until it's ALL there.

22 pages, over 500 posts and it seems like were all still saying the same stuff, just louder.
 
cracauer@ said:
The question is whether there will still be a `make install` after compilation, or whether you have to go through making packages and installing those.
Click to expand...
If "make install" doesn't get used (by the developers) it will rot. But I sort of doubt developers would want to wait longer for a package to build. A package adds extra *packaging* related dependencies.
 
LibreQuest said:
Don't stop using FreeBSD based on these types of changes. The license allows you to build your own project based on the FreeBSD system.
Click to expand...
I know how to do software engineering, and I do it for a living. But for my production OS at home, I don't want to do my own development; I want to use a packaged system that "just works". With the minimum hassle. So forking FreeBSD is a non-option. For the same reason, I don't compile the system or any ports; I run release versions only, and install only binary packages.
 
ralphbsz said:
I know how to do software engineering, and I do it for a living. But for my production OS at home, I don't want to do my own development; I want to use a packaged system that "just works". With the minimum hassle. So forking FreeBSD is a non-option. For the same reason, I don't compile the system or any ports; I run release versions only, and install only binary packages.
Click to expand...
If that works correctly/as expected for you (POLA), old update or pkgbase should be transparent, no?

Example:
System uses pkgbase and the freebsd-update command has been converted to a wrapper around appropriate pkg commands.
User experience should not change: you do freebsd-update fetch && freebsd-update install and your system goes from FreeBSD-Release-NN.YY-pX to FreeBSD-Release-NN.YY-pY.

Now where I think it gets interesting is across releases (because this is how I upgrade across releases like 12.x to 13.x, 13.x to 14.x, etc):

I can currently do (grossly simplified):
bectl create nextversionBE
freebsd-update -r nextversion into chroot
pkg upgrade into nextversion chroot
bectl activate nextversionBE
reboot

and I'm in a coherent BE on "next version".
If pkgbase still lets me do a similar "concept", it's a noop to me.
If it won't let me do something like that, it sucks.

Right now pkg repo definitions has reference to "what you are running" so you need to edit files to switch from quarterly to latest for ports. Is that how we'll migrate across releases? We'd need to do that edit for all the repos, no? And exactly what will that mean? I want my 15.0-RELEASE ports/kmods (FreeBSD, FreeBSD-kmods) to to follow 15.0 Quarterly, but to pick up 15.0-RELEASE (from my 14.x-RELEASE) I need to modify my FreeBSD-pkgbase to point at latest?

My opinion only:
I don't think pkgbase is necessarily bad (systemd is bad by default), but perhaps user concerns related to usage patterns of freebsd-update have not been addressed or documented/conveyed to the community.
Upgrading systems across releases is not the same as fresh install on new release and toss in ZFS BEs? Answers probably come down to "we didn't think of that, blah blah blah".

How about we get the pkgbase devs to read through this thread and maybe address concerns that have been raised?
 
cracauer@ said:
The question is whether there will still be a `make install` after compilation
Click to expand...
I implied that the process of compiling, installing and configuring source code is needed for a package manager, in this case, pkgbase to exist. Pkgbase isn't going to magically have packages without that process.

When ports are built, there's still a sequence of make commands (porters handbook full of sequences) to do. pkg install still relies on the results of that other set of commands. Make install is still used to make packages by maintainers for pkg. Whatever pkgbase does, the traditional way will still be behind the scenes, maybe not seen to the pkg user.

That pkgbase relies on built sourcecode implies that make install and mergemaster will still be used. Building from source for ports/packages uses the same process, and pkg just simplifies that for the end user. The only way not is if another way comes along, which will be independent of pkgbase, maybe influenced by, but used without pkgbase. Otherwise there won't be the way the developers put it together to package it for pkgbase. The source code compilation is the underlying and independent part that a package manager is dependent on.

Both base packages and port packages were described as a comparison, going back and forth between them.
 
cracauer@ said:
The question is whether there will still be a `make install` after compilation, or whether you have to go through making packages and installing those.
Click to expand...
I don't see how it's technically feasible not to build pkg first. The package database will have huge drift. Unless it's handled the same way ports are. We take it for granted, but the FreeBSD ports system is a technical marvel.
 
mer said:
If that works correctly/as expected for you (POLA), old update or pkgbase should be transparent, no?
Click to expand...
That is indeed the big if.

Why do I do FreeBSD updates (even major version upgrades) on a live system? Because: (a) If have backups of all user data (/home and a few things in /var) and configs (/etc and friends). (b) I have ZFS snapshots and boot environments. And most importantly (c) because I have done it dozens of times for minor versions, and a handful times for major versions, and it has never caused a problem.

How many times have I done a FreeBSD update using pkgbase and it worked perfectly? How many times have I converted a traditional system to pkgbase? Zero. Therefore there will have to be a trial run, which means setting up a separate system (can be in a VM or in the cloud) to test the upgrade on.

Now that doesn't mean that I'm against the FreeBSD community improving its packaging and upgrade tools. On the contrary: Improvement is good! But change will cost me a few hours to test the change.

But the other important thing is to contrast that with upgrades in the Linux environment: I have yet to see any Linux distribution where I expect minor and in particular major version upgrades to work at all. As I said already: I will always do re-installs when a major version upgrade is necessary on Linux, since my expectation (well founded, sadly, based on RHEL and Debian) is that the in-place upgrade will fail. I know it is theoretically possible to upgrade Linux systems in place, and I've worked with a Linux distribution (called Rodete, not publicly available) that is capable of doing it, but I know of no free one. So FreeBSD is way ahead on this criterion, but it might be throwing that advantage away.

I don't think pkgbase is necessarily bad (systemd is bad by default), but perhaps user concerns related to usage patterns of freebsd-update have not been addressed or documented/conveyed to the community.
Click to expand...
Agree: pkgbase it not necessarily bad, but it may end up being badly implemented, or it may be done wonderfully.
Disagree: systemd is not bad, as long as you don't look at how it is internally implemented; from the viewpoint of a user or administrator it works fine, and has considerable advantages.
Agree: The documentation and justification of pkgbase is sorely lacking.

How about we get the pkgbase devs to read through this thread and maybe address concerns that have been raised?
Click to expand...
That would be great. But remember, this is a user forum, not a conduit to developers or the foundation. We can't have an expectation that they will respond here. And if they don't, there will be fewer FreeBSD users, which doesn't bother me.
 
Alain De Vos said:
It has a very small user base. Not one review on distrowatch.
Click to expand...

These are two different things, one of them is true. Distrowatch just isn’t the canonical review database for actual Unices. Not every community spends much of their time there. :)

Alain De Vos said:
Can you boot it with grub ?
Click to expand...

OpenIndiana comes with its own boot loader. I’m not an expert on either grub or OpenIndiana, but you should be able to just chainload it.
 
I failed to install openindiana. First it crashed during install going into graphics mode. Later my bios did a disk renumbering so it didn't boot no more. Currently i'm trying out in virtualbox.
Which is slow as hell. So i dumped it.
 
Last edited:
You must log in or register to reply here.
Back
Top