Future upgrade from 14.x to 15 - pkgbase?

F

fmc000

I'm trying to understand what pkgbase is and what will happen when 15 is released with regards to upgrading 14.x installations to it. It's my understanding that freebsd-update will no longer be available in 15 so how will this transaction be managed?

Automatically?
By hand?
Upgraded installations will still have freebsd-update?
With pkgbasify?

HEAD slush is less than two weeks ahead...
 
For what I have understood (and experienced), you can switch to pkgbase (manually or with pkgbasify; I used the manual method), but then, you can't use freebsd-update anymore (at least, it's not advised). I didn't see a way to return to a 'freebsd-update' system.

I used this to make some tests: https://wiki.freebsd.org/PkgBase

I started from 14.1-RELEASE or 14.2 and upgraded up to 14.3-RELEASE. It's just working. I failed to upgrade to 15-CURRENT, but I think it's a bug in pkg (as it segfaults).

My opinion is pkgbase is usable but not mature yet. I won't use this for the moment.
 
Emrion said:
For what I have understood (and experienced), you can switch to pkgbase (manually or with pkgbasify), but then, you can't use freebsd-update anymore (at least, it's not advised). I didn't see a way to return to a 'freebsd-update' system.
Click to expand...
Probably the same sort of set up as with the old package tools and PKGNG (now pkg(8)), you could convert your system from the old package system to PKGNG but not the other way around.

I suspect freebsd-update(8) will continue to work on 15.x, but with a gentle nudge towards Pkgbase. And completely removed with 16.0. Changes like this typically take 1 or 2 major versions to complete.

Another example is the switch from sendmail(8) to dma(8), 13 had both sendmail(8) and dma(8) but had sendmail(8) enabled by default, with 14 the default switched to dma(8) but sendmail(8) is still included. Only with 15 would sendmail(8) be entirely removed.
 
Thanks everyone, I will probably use my test VM to try it. I really don't like the concept, though; to me it looks like throwing away a lot of what FreeBSD is.
 
fmc000 said:
Thanks everyone, I will probably use my test VM to try it. I really don't like the concept, though; to me it looks like throwing away a lot of what FreeBSD is.
Click to expand...
NOTE:
Before I say anything else, I have nothing invested in pkgbase, haven't used it, so just asking/opining. You may agree, disagree, I really don't care. Discuss the points, don't reflexively dismiss the point.
And apologies in advance if I write too many words.

I've seen this expressed a few times but I don't understand "why" people think that way.
You say you don't like the concept, why?
If you are using ZFS, create a new BE, then in the new BE do the "pkgbasify" and you don't lose anything.

Right now freebsd-update downloads patches for kernel and userland and lets you install them (update to them). If an update is to just say sshd, the forum sees a lot of threads "I just updated to -pX and freebsd-version -kru shows only u being at -pX. Why? Is it broken?" Then the answers are "the update only affected a userland component, not the kernel".

So pkgbase, if it's taking "freebsd base of kernel and userland" and chopping it up into a bunch of logical units that can be maintained by the standard pkg command, what is the problem?
I can see a CVE can be released quicker for a single component.
Can we really wind up with a pkgbase system that has userland out of whack with kernel? To me this is a "repo management issue"; whatever is actually in the pkg repos must be coherent, so pushing must be moderated.

My issue would be related to the "freebsd-version" command. That's muscle memory we all do "freebsd-version -kru" to figure out what we are running.
What does that look like on a pkgbase system? I don't know.

To me, I think it's a sixes and threes. It's different from the historical stance, but is it actually bad or is it just different? I don't know because I've not used it, but arguments I've seen that state "...trying to Linuxize BSD" just make me want to grab a beer and popcorn.
 
mer said:
So pkgbase, if it's taking "freebsd base of kernel and userland" and chopping it up into a bunch of logical units that can be maintained by the standard pkg command, what is the problem?
[...]
just make me want to grab a beer and popcorn
Click to expand...
Tell you what. If *all* they do is chop it up and base still remains as consistent as it is now; then I'll buy you a beer to go with that popcorn. Otherwise, beers on you so we can all drown our sorrows! ;)
 
kpedersen said:
Tell you what. If *all* they do is chop it up and don't add or remove any packages for a couple of years after that; then I'll buy you a beer to go with that popcorn. Otherwise, beers on you so we can all drown our sorrows.
Click to expand...
Done, handshake, written in my will.

Maybe forum threads like this where users are expressing concerns can provide feedback to the project about "optics".

As I've said, I have nothing invested in it, I can see pros and cons. Historically is things that have been in "base" that wind up migrated to "contrib" (openssh/openssl jump to mind); sendmail/dma is another. If one takes a big step back and puts on blinders, there is an argument "if its in contrib and we don't have local modifications, should it be in base".
But I'm not going to make that for or against argument.
 
Has there been any official documentation produced yet? before we break out the pitchforks... reminds me of the svn to git hysteria.
 
  • Like
Reactions: mer
mer said:
I've seen this expressed a few times but I don't understand "why" people think that way.
You say you don't like the concept, why?
Click to expand...

What I like most of FreeBSD is that the kernel and _all_ the userland are a coherent monolith. If you make a mistake of you simply want to restart from scratch the solution is just a tar command away. It is my understanding that this will not be possible anymore with pkgbase (I may be wrong, of course, and I thank in advance everyone that will correct me if this is the case).
 
It will be possible. just like you do unpack the "base" tarball over the failed attempt, you would just pull your "base" from pkg repository. in the end you getexactly the same base.
 
Thank you for starting this thread; I hope lots of useful information and interesting viewpoints will emerge.

fmc000 said:
What I like most of FreeBSD is that the kernel and _all_ the userland are a coherent monolith.
Click to expand...
From my limited viewpoint: I find coherent much more important than monolith.
 
fmc000 said:
What I like most of FreeBSD is that the kernel and _all_ the userland are a coherent monolith.
Click to expand...
When you have a security update, only userland or kernel can be updated. Not that a monolith.

pkgbase is just another tool/means to update kernel & userland. As I said, it's somewhat bugged for the moment, so I won't use it. But if this becomes the only way to update/upgrade, well...

There are serious advantages using pkgbase: speed of updating/upgrading. It took only a couple of minutes comparing to an hour or more with freebsd-update. Also, you can have a STABLE or a CURRENT version up-to-date without compiling (so energy and speed gains).
 
Other than that you also have information of base's pkg by means of pkg - contents, size, libraries, linking. to this day it was not possible ( to me at least ) without find grep ldd or similar
 
kpedersen said:
The repo moved to git and svn (and svn-lite) was removed from base.

So basically we need to grab Git/Got from ports/packages.
Click to expand...
Back when the sources were under CVS you had to install a port/package to update the source and/or ports tree too.
 
SirDice said:
Back when the sources were under CVS you had to install a port/package to update the source and/or ports tree too.
Click to expand...
Yeah, its odd that the main CVS implementation was a GNU/GPL thing. OpenBSD kept it in base but worked on OpenCVS (which I think is now not seeing much development work).
 
fmc000 said:
I'm trying to understand what pkgbase is and what will happen when 15 is released with regards to upgrading 14.x installations to it. It's my understanding that freebsd-update will no longer be available in 15 so how will this transaction be managed?

Automatically?
By hand?
Upgraded installations will still have freebsd-update?
With pkgbasify?

HEAD slush is less than two weeks ahead...
Click to expand...

This is not an issue if you just stay on -current, smoothly sailing into 16-current land without noticing a thing about pkgbase :)
 
You must log in or register to reply here.
Back
Top