!!!!WARNING ALL FREEBSD DESKTOP USERS!!!! : Insane pkg's new version upgrade of installed apps

[T-Aoki]

Ouch. That's a high volume list if you don't procmail it.

I'm checking here with the archive from time to time, not subscribing.

 

[astyle]

Ouch. That's a high volume list if you don't procmail it.

I'd think that 'pkg being problematic' is one unfortunate reason for that ML to be THAT high-volume...

 

[Charlie Brown]

For my part, there is no reason for PKG to have acted like this. I'm running 14.3 stable and I just did the update upgrade and reboot. No ports installed. So if it works for you, why not for me ? But yes, other than that, lesson learned wait and simulate before update.

The problem is that one package was marked to be removed the others were mark to be updated and reinstalled, but an all bunch of packages marked to be reinstalled have been deinstalled but not reinstalled.

 

[T-Aoki]

poudriere bulk builder detects OSVERSION upgrade and delete all pkgs before starting actual builder jails,

Forgot to mention.
As far as I've experienced, poudriere forces full rebuilds at least when whichever of below happenes.

• When OSVERSION (generated based on __FreeBSD_version defined in /usr/include/sys/param.h) is bumped (even in lowest significant digit!).
• When BRANCH (STABLE, ALPHA5, RELEASE,...) in /usr/src/sys/conf/newvers.sh is changed.

Note that when OSREL (13.5, 14.3, 15.0,... coming from REVISION in /usr/src/sys/conf/newvers.sh) is bumped, OSVERSION is bumped, too.

 

[astyle]

More and more gotchas... This is really firming up my resolve to stick to ports and fresh installs. The User Handbook does not really mention those pkg-upgrade(8) and freebsd-update(8) gotchas, either.

I know one is supposed to RTFM... but it does look like there's actually a long list of gotchas and details to line up so that pkg-upgrade(8) and freebsd-update(8) work as intended / advertised.

 

[cracauer@]

I'd think that 'pkg being problematic' is one unfortunate reason for that ML to be THAT high-volume...

Well, if you do use procmail you could filter out build failures for the packages you care about. That way you get an early warning.

 

[bakul]

If I understand you correctly, the workflow used by the system that creates packages for RELEASE is the following:

1. On October 1st, create a new empty package directory for the current quarter.
2. Begin populating it with newly built packages. This takes several days.
3. Use the created packages for the remainder of the quarter, unless they need to be regenerated.

And: if anyone runs a "pkg upgrade" command between steps 1 and 2 above (when the new quarterly repo is only partially populated), they will get some of their installed packages deleted. In other words, there is a window of several days every quarter (or roughly several percent probability) where an host is at high risk of having packages wrongly uninstalled.

If true, that would mean that the "pkg upgrade" mechanism has only a reliability of 1-2 nines (about 90% to 99%). That would be insanely bad.

*If* this is how packages are created, they should rename the directory (an atomic operation) *once* the pkg dir is fully populated. Partially populated pkg dir should never be visible to users. [A reason to not use a zfs mountpoint for pkg dir]

I usually do a pkg update && pkg upgrade and so far have not run into problems.