pkgbase upgrade freebsd 15.0 to freebsd15.1 was so complex. why ?

I've been asking myself the same thing ever since it was announced that this will be forced upon everyone from 16.0 onwards...
Initially it was communicated this will be a separate tool - so we at least would keep the important distinction between base system and third party software (ports); but now its all just a mishmash botched into pkg.
This feels like something straight from linux-land: replacing something that wasn't broken with something that is; then forcing it down everyones throat even if that new thing isn't nearly on-par with what the previous tool was capable of. (there is still no rollback? IDS? a '--currently-running' option to upgrade a host system via jail? no automatic handling of BEs?)
 
fff2024g said:
Why is it so complicated to upgrade a FreeBSD 15.0 to FreeBSD 15.1 with pkgbase ? It's much harder than the old freebsd-update upgrade -r 15.1-release. So then, what's the point of developing pkgbase?
the guide link: https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-pkg
that make me crazy ...thanks.
Click to expand...
There are several reasons.

But first, it's not replaced as freebsd-update lives yet. For the moment, it's a user choice to install with pkgbase a new system or pkgbasify an already installed one. I heard that it will replace classic update/upgrade/installation, but in an undefined future.

Reasons:
- Update and upgrades are way faster.
- Access to updates and upgrades that were previously only possible by compiling the source (STABLE, CURRENT). You can even downgrade (but it may interest noone, lol).
- At install time (or for a jail) you have a more fine grained choice of the base components you want.

Drawbacks:
- For the moment, you have to do upgrade "at hand" without a dedicated command. It will change in a near future I hope (with freebsd-update itself, I read).
- Less separation between base and third-party packages. Time will tell if this is uncomfortable or not.
- Younger, so more buggy.

Note: I keep all my important station/server under freebsd-update for the moment.
 
Emrion said:
Reasons:
- Update and upgrades are way faster.
Click to expand...
I couldn't care less. Minor upgrades are quite fast and for release-updates one is planning a reasonable downtime anyways. This sounds like that bogus and completely useless "it boots faster" argument we all heard once... A tried and proven upgrade procedure *FOR THE OS ALONE* that just works is always faster. I don't want OS upgrades bundled with third party software upgrades - this has been separated for very good reasons and mixing those up *will* cause breakage.

Emrion said:
- Access to updates and upgrades that were previously only possible by compiling the source (STABLE, CURRENT). You can even downgrade (but it may interest noone, lol).
Click to expand...
Given everything now has to be a package, you have to compile everything anyways *and* build complete packages; so I guess you'd also need a fully-fledged poudriere build environment for that?
Currently if you need a specific patch for your base system that isn't yet included in e.g. -RELEASE, you'd simply build base once and then you can re-build only the parts that you need to patch. You can even simply drop in that single file (e.g. kernel module) from the build directories (or even a different host) into the target directory without the detour through a fully-fledged package.
And TBH - how often do you need this on a production server/system? This sounds way more like a development or hotfix thing, which would be absolutely *no* justification for complicating (breaking) OS updates for everyone...

Emrion said:
- At install time (or for a jail) you have a more fine grained choice of the base components you want.
Click to expand...
base is base. period. FreeBSD is a coherent operanting system, not "a kernel plus some opinionated stuff we duct-taped together and you can pick and replace as you like" - that would be linux.
 
What if the pkg command ignored the "OS packages" by default? Then unless the user tells it to it will only upgrade applications.
Then add a new flag or new command or modify freebsd-update to handle pkgbase.

Doing both of those keeps everything in line with POLA.
 
sko I see you are completely against pkgbase. It's your right and, in some ways, I understand: you have something that works, so why change it?

You forget two things:
- Not all the people that uses FreeBSD have the same needs than you. For example, I'm very bored by the time taken for an upgrade with freebsd-update. I don't speak of those who have several thick jails. It's the only reason why I chose thin jails, by the way.
- FreeBSD devs have chosen to follow the pkgbase path. They aren't stupid, are they? If something goes wrong with pkgbase, I mean with its very concept, they will cancel the project. They are pragmatic and it's why FreeBSD is always there.

Beside all the technical or emotional points, I'm very pleased by the arrival of pkgbase, because it will avoid useless compilation. I mean those who want to compile for whatever reason will continue to do so, but some others that just want to follow a STABLE or CURRENT branches won't. And it's good for the planet.
 
  • Like
Reactions: mer
sko base was never fixed. FreeBSD base was extracted from tgzs since day 1, and you had a choice to make a full or partial install.

The debug versions of the binaries, system source, ports tree, 32-bit compatibility libraries are all parts of the base that use a lot of space and are at large not used on a modern server platform, but all are valuable on the desktop.

Pkgbase is currently complex. I believe the end goal is to wrap it all behind freebsd-update tool.
It has been deployed in this rough-around-the-corners shape to pick up relevant and valuable data from real world testing.
Has it occurred to anyone that FreeBSD does not have 500 testers on 9-to-5 ready to pick up tasks?

Why pkgbase approach is not bad (subjectively) has been explained with (objective) comparison to Linux, in other threads, there are many.

Whining about pkgbase is totally moot, it is not going to go away and you can only help by using it and not by avoid and rant.
The more it is used, the better the implementation of new freebsd-update tool will be.
 
I don't think it's complicated (in my opinion freebsd-update is way more complicated, it just hides lots of stuff, people are just used to it), you just need to adjust the pkg configuration file to point to the release you want, update (i.e. pkg update -f, saying yes to the prompt about versions) and then re-install all packages from at least base and kmods (i.e. pkg upgrade -f -r FreeBSD-base && pkg upgrade -f -r FreeBSD-ports-kmods), ports should work unless you are upgrading between majors (so a simple pkg upgrade -r FreeBSD-ports should be enough).
Out of caution disable loading any kmods in /etc/rc.conf (i.e. amdgpu, i915kms, nvidia etc) then reboot.
If anything goes south, either downgrade (should work locally with what the packages you have in /var/cache/pkg) or if rollback to a previous BE/snapshot and ask for help.

Comparing this with non-rolling Linux distros like debian, rhel clones, etc, the system is very similar with the same caveats.
 
fahrenheit said:
I don't think it's complicated (in my opinion freebsd-update is way more complicated, it just hides lots of stuff, people are just used to it), you just need to adjust the pkg configuration file to point to the release you want, update (i.e. pkg update -f, saying yes to the prompt about versions) and then re-install all packages from at least base and kmods (i.e. pkg upgrade -f -r FreeBSD-base && pkg upgrade -f -r FreeBSD-ports-kmods), ports should work unless you are upgrading between majors (so a simple pkg upgrade -r FreeBSD-ports should be enough).
Out of caution disable loading any kmods in /etc/rc.conf (i.e. amdgpu, i915kms, nvidia etc) then reboot.
If anything goes south, either downgrade (should work locally with what the packages you have in /var/cache/pkg) or if rollback to a previous BE/snapshot and ask for help.

Comparing this with non-rolling Linux distros like debian, rhel clones, etc, the system is very similar with the same caveats.
Click to expand...
It's not, especially now that bectl can allow a quick rollback if things go south. Not that the alternative of using ZFS snapshots is impossibly hard, but bectl does make it super useful

The bigger annoyance IMHO, is the lack of a simple way of uninstalling all packages except base. Although, I assume that that's coming eventually, but allowing pkg delete -fa to also nuke both the kernel and rescue dir without asking explicitly to do it is probably not a good design decision. Rm -Rvf has always been dangerous, but pkg delete already has an exception to prevent it from deleting itself.
 
Back to the Op question, for those who feel adventurous, I wrote a script that reproduce some features of freebsd-update but for pkgbase. Its syntax is even simpler, I never understood why to upgrade you need this "-r" with freebsd-update.

Here, it's just: pkgb-update upgrade 15.1-RELEASE

Warning: you do it at your own risk, this script is experimental. Don't do that with UFS on root unless you have a solid backup. On ZFS, create a Boot Environment before!

github.com

GitHub - Emrion/pkgb-update: A tool to make upgrade with pkgbase easy

A tool to make upgrade with pkgbase easy. Contribute to Emrion/pkgb-update development by creating an account on GitHub.
github.com github.com
 
Pkgbase is different ok
But to say that the procedure is complicated is surprising from some users who are administrators And they have been for years To say that everything is mixed up is false There is always a separation between third-party pkgs and the system The update system will eventually be a procedure called "freebsd-update" And I'm sure it won't require 3, 4 reboots
 
fjdlr said:
Pkgbase is different ok
But to say that the procedure is complicated is surprising from some users who are administrators And they have been for years To say that everything is mixed up is false There is always a separation between third-party pkgs and the system The update system will eventually be a procedure called "freebsd-update" And I'm sure it won't require 3, 4 reboots
Click to expand...
As a result of my tests, you don't need to deactivate third-party kernel modules and only one reboot is needed.
 
I didn't even know that there was a upgrade tool.
I always used freebsd-update and lately the only problem I have is related to i915-dkms drivers and the system turns into a boot loop breaking the upgrade process.
To update the drivers I must have a session, right?
If the driver doesn't load it should fallback to some default that whatever works, VGA or VESA.
But it turns into a kernel panic and reboots, really?
If I use a bootable USB stick with FreeBSD 15.1 it boots fine with default graphics (no i915-dkms), what's the problem on making this the fallback?
What I did? I had to boot with USB stick, mount UFS in /mnt and edit etc/rc.conf in order to disable i915 and disable sddm which in fact doest not work too for wayland sessions, it just works for X11.
 
sko said:
Given everything now has to be a package, you have to compile everything anyways *and* build complete packages; so I guess you'd also need a fully-fledged poudriere build environment for that?
Click to expand...
So much for the argument that it will be faster - at the moment I only need to build the source and install; next I'll have to build the source, build the packages and then install. Pfft.
 
trev said:
So much for the argument that it will be faster - at the moment I only need to build the source and install; next I'll have to build the source, build the packages and then install. Pfft.
Click to expand...
Why? Why do you think the standard make world make installkernel make installworld will not keep working?
 
fahrenheit said:
Plus, creating packages is very fast. What takes time is actually compiling stuff.
Click to expand...
I doubt that anyone that builds from source would object to the wall time; my objection would be the extra complexity. install[kernel,world] + etcupdate is simple and works really well - there's more that can go wrong with an intermediate pkg repository.
 
bob2112 said:
I doubt that anyone that builds from source would object to the wall time; my objection would be the extra complexity. install[kernel,world] + etcupdate is simple and works really well - there's more that can go wrong with an intermediate pkg repository.
Click to expand...
But what if the output of "make buildworld/buildkernel" was a set of packages? And "make install" correctly understood how to deal with them?
Transparent to the user.

Honestly a lot of the "discussions" around pkgbase are starting to sound like "it's changing and I don't want to change" rather than technical arguments as to why it's bad.

So far, to me, the only valid thing is "pkg upgrade" may upgrade base and third party at the same time (the Linux model) That is why I keep saying "by default if pkg command ignored "base" repos then the user maintains the "I can update applications separately from OS"

Sorry, but I'm starting to feel like folk are stirring the pot without looking at technical reasons.

And that's my opinion. Agree, disagree, tell me I'm full of crap, I don't really care. Because we all know what opinions are like :)
 
I haven't switched to pkgbase yet because I don't have time to fully understand how it works, especially (as mer said) if I'll run into problems after switching. I use ports, but some operations, such as requesting ports to update (pkg version -L '='), could interfere with the system's base packages. In short, I haven't considered all the possible drawbacks yet because I don't consider myself an 'advanced user' at all: I've never installed a jail, I've never compiled the system from source, and I've never delved into the ins and outs of the system. I use FreeBSD because I think it's an excellent operating system, both as a server and as a desktop. I've always wanted a server in my small office (and at home), and I've had one for twenty years. For a few years now, I've been using XFCE almost exclusively with FreeBSD (in VirtualBox) and I'm very happy with it. I've always used freebsd-update to update systems and never worried about what it did or why, it just works. Now I need to change, because freebsd-update also ends with version 15. But reading the issues that have arisen and been resolved on this forum, I'm not sure whether to make the final decision to switch to pkgbase. I thought that in the meantime, before the 16.0-RELEASE release will be out, the freebsd-update script would be modified to handle pkgbase (which is what emrion is doing and already did an excellent job with sysutils/loaders-update) so that the switch would be painless.

Anyway, this isn't my complaint about pkgbase, it's my fault for not being informed about this new tool and having little time to dedicate to it. Thank you emrion to work on a new freebsd-update, I will use it.
 
mer said:
But what if the output of "make buildworld/buildkernel" was a set of packages? And "make install" correctly understood how to deal with them?
Transparent to the user.

Honestly a lot of the "discussions" around pkgbase are starting to sound like "it's changing and I don't want to change" rather than technical arguments as to why it's bad.

So far, to me, the only valid thing is "pkg upgrade" may upgrade base and third party at the same time (the Linux model) That is why I keep saying "by default if pkg command ignored "base" repos then the user maintains the "I can update applications separately from OS"

Sorry, but I'm starting to feel like folk are stirring the pot without looking at technical reasons.

And that's my opinion. Agree, disagree, tell me I'm full of crap, I don't really care. Because we all know what opinions are like :)
Click to expand...
Pkg upgrade without arguments updates everything sure, but -r exists, so you can skip base if you wish, just wrap/alias pkg for convenience.
Dependency resolution it's not one of pkg's strong points so there may be incompatible upgrades say for example with linuxkpi (on stable for sure on releng maybe?).
 
You must log in or register to reply here.
Back
Top