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.
 
You must log in or register to reply here.
Back
Top