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

freethread said:
Now I need to change, because freebsd-update also ends with version 15.
Click to expand...
No, and that's for sure. I think that updates/upgrades without pkgbase will remain in 16 era, at least.
FreeBSD is somewhat conservative and prudent in its advances. That's not Linux.

That doesn't mean you don't have to prepare to the jump.
 
fahrenheit said:
Pkg upgrade without arguments updates everything sure, but -r exists, so you can skip base if you wish, just wrap/alias pkg for convenience.
Click to expand...
I understand that BUT the current behavior of pkg is "upgrade only third party things". So I' suggesting that by default if you do "pkg upgrade -y" it should NOT look at pkgbase repos. That preserves exsiting behavior, adhering to POLA (Principle Of Least Astonishment) and frankly gets rid of arguments about updating OS and third party at the same time (Linux Model) Then another tool (freebsd-update) that understands pkgbase or an option added to pkg command like "--doonlypkgbase".

So, again, my opinion, current arguments around pkgbase have some valid input/concerns, but it's not the default which means it's maturing, so how about we work to improving it instead of just saying it sucks?
 
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.
Click to expand...
For most of us, pkg is a black box which is the opposite of transparent.

My suspicion is that the extra complexity of pkgbase will lead to more updates that require special handling, and more problems - this thread is probably one of the latter.
 
bob2112 said:
For most of us, pkg is a black box which is the opposite of transparent.

My suspicion is that the extra complexity of pkgbase will lead to more updates that require special handling, and more problems - this thread is probably one of the latter.
Click to expand...
It's a black box as much as freebsd-update is, the source is available.
No one is forced to use packages, source builds will continue to work.
If one doesn't want base as packages just build from source. In fact I bet someone will reintroduce the old freebsd update in 16. That's the way oss works.

mer I was overcomplicating, just disable the FreeBSD-base repo on pkg.conf, pkg upgrade will just upgrade ports. You can re-enable on minor upgrades or patch releases.
And you are right, FreeBSD 15 is the release where we can make sure pkgbase is sane and a good tool going forward.
 
but freebsd-update and pkg tools aren't good enough?
yes, build from source will surely work but it takes lots of time to achieve the same result as freebsd-update unless of course there are custom build parameters.
 
rmomota freebsd-update is much more complex than pkg. Look into the source.

The security patches coming for 15.0 are applied in under a minute on the pkg run.
Whoever has ran freebsd-update, knows it runs for long. Why? Because it is a complex piece of software that works on dynamic basis, figuring out the whole base OS installed, and then figuring out what patches to bring in. Pkg brings a state to this. The base OS is known, the tools don't need to dig through the hard drive to know what update to request.

bob2112 said:
For most of us, pkg is a black box which is the opposite of transparent.
Click to expand...

Err no it isn't. You have the source, you have the open repos, and you have insight into the process of how repos are formed.

What exact black box behaviour are you talking about?

freebsd-update is less transparent. It actually tells you nothing. Pkg actually tells you what exact component is it going to touch.
 
bob2112 said:
We were discussing the hypothetical removal of straightforward source builds in the future.
Click to expand...
I disagree. An assumption was made (paraphrased) that pkgbase would prevent source builds which from everything I've seen is an incorrect assumption.
pkgbase packages need to be built from source, no?
Simplistically, it's the output; pkgbase simply gives more granularity than the old distribution sets.
Honestly, why not ask the question over on the mailing lists:
If I have a package base system, can I still make buildworld make buildkernel make installkernel make installworld? Are there any extra steps?

That way the developers can provide a definitive answer to the question instead of speculation here.
 
mer said:
I disagree. An assumption was made (paraphrased) that pkgbase would prevent source builds which from everything I've seen is an incorrect assumption.
pkgbase packages need to be built from source, no?
Click to expand...
It was you who postulated that source builds might involve intermediate packages.
 
bob2112 said:
We were discussing the hypothetical removal of straightforward source builds in the future.
Click to expand...
and how are gonna do that?
close all the source or part of it?
as soon as the source is available source builds is always possible and as soon source is no longer available that will be the day I will stop using FreeBSD and believe me most people will too.
I don't usually build from source but I did it already, for some reason I don't remember and had to change some parameter to enable something, and this gives me the feeling of full control over the system and I would like to keep it that way.
will freebsd-update be discontinued?
do I need to start using pkgbase asap?
 
rmomota said:
and how are gonna do that?
close all the source or part of it?
as soon as the source is available source builds is always possible and as soon source is no longer available that will be the day I will stop using FreeBSD and believe me most people will too.
I don't usually build from source but I did it already, for some reason I don't remember and had to change some parameter to enable something, and this gives me the feeling of full control over the system and I would like to keep it that way.
will freebsd-update be discontinued?
do I need to start using pkgbase asap?
Click to expand...
Freebsd-update as is will be discontinued on 16. So in essence you still have ample time to try pkgbase.
Until 16 is released my expectation is that most of this kinks will be addressed.
 
fahrenheit said:
Freebsd-update as is will be discontinued on 16. So in essence you still have ample time to try pkgbase.
Until 16 is released my expectation is that most of this kinks will be addressed.
Click to expand...
that is something I liked when I started using freebsd
use freebsd-update, a separate tool to update/upgrade the system
pkg to manage software
now it will become the same tool for both
If that's the case so I hope to have that dkms problem automatically resolved on next upgrade as system and packages will be updated all at same time, right?
 
Hi!
This thread is Solved but I would like to know if it makes sense to start using pkg base after already upgraded to 15.1 with freebsd-update?
How to properly setup pkg base, once it will be the future of freebsd upgrades, to start receiving 15.1 system security updates/patches from now on?
I have these components enabled
Components src world kernel
Is it as simple as this?
Is there any risk of messing up the system doing this now?
 
After 15.0, we are in the stabilization phase of pkgbase.

Is it safe? Nothing is, not even any freebsd-update. So make a BE if you use zfs on root or a backup for ufs.

It works, but I don't use it on critical machines, yet. Time will come, for sure.

You can use pkgbasify.lua or the "new quick instructions".
 
Emrion said:
After 15.0, we are in the stabilization phase of pkgbase.

Is it safe? Nothing is, not even any freebsd-update. So make a BE if you use zfs on root or a backup for ufs.

It works, but I don't use it on critical machines, yet. Time will come, for sure.

You can use pkgbasify.lua or the "new quick instructions".
Click to expand...
Stabilization phase; good choice of words.
If pkgbase is default in 16, I wonder if one will be able to use freebsd-update across to the new 16.0 release and wind up with pkgbase system. I'm assuming the answer will be yes.

Roughly (using the chroot options for freebsd-update and pkg):
starting at 15.X-RELEASE-pY on ZFS
create new BE 16.0-RELEASE-p0
bectl mount 16.0-RELEASE-p0 /mnt
freebsd-update -c /mnt upgrade -r 16.0-RELEASE-P0 (update into the new BE)
freebsd-update -c /mnt install (repeat as needed)
pkg -c /mnt upgrade -f
 
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...
Your experience was rather different to mine.

I felt the process was better. The first host was slower than the subsequent hosts. I had things to learn and questions to ask. But then, I also had similar questions over my years of using freebsd-update. I am much more familiar with freebsd-update than pkgbase and my experience with it has been overwhelmingly postive.

However, I welcome the new approach. The next 8 hosts I updated were much faster than the first one. I'm looking forward to using this for my jails too.

Change takes time. I hope your experience improves.
 
Emrion said:
It works, but I don't use it on critical machines, yet. Time will come, for sure.
Click to expand...
how I read it, it works but it's not yet properly tested.
So I will keep using freebsd-update until it's good to go.
I know any method can go wrong but I've been using the good old freebsd-update and never got problems.
Using pkg base for dealing system binaries as packaged files seems to be a good and a bad idea at same time.
Good because when the system updates it will also update dkms drivers and no more broken system boot after a upgrade.
Bad because I like the idea of having a full set of binaries that got built all together and now having it split in packages I can't be sure of it.
Well the fact is that I can't also be sure of the first one too unless I build it myself.
 
You must log in or register to reply here.
Back
Top