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