On 2016-01-27 23:33, Glen Barber wrote:
As many know, work has been in progress for quite some time to provide
the ability to package and upgrade the FreeBSD base system using pkg(8).
The majority of the initial implementation has provided much of the core
functionality to make this possible, however much work still needs to be

Over the past few weeks, there have been several inquiries on if this
work is still targeted for the 11.0-RELEASE, as well as the status of
the project branch (base/projects/release-pkg).

The answer to the first question is: Yes.  This is still targeted for
11.0-RELEASE, which was one of the requirements during discussion of the
new support model announced early last year [1].

The status of the in progress work is a bit more complex to answer in
a short email, but work on packaging the FreeBSD base system is indeed
ongoing, and has been my primary focus over the past several weeks.

I am finishing an initial list of outstanding items that need to be
resolved before the project branch can feasibly merged back to head,
which I will send to the new freebsd-pkgbase@ mailing list.  People
interested in discussion surrounding this topic are urged to subscribe:


Finally, I want to personally thank Baptiste Daroussin for all of his
tireless efforts to get us to the point we are at now.  Without his
ideas and insights, as well as ensuring pkg(8) contained the necessary
functionality, we would not be anywhere close to completing this work
for the 11.0-RELEASE.
May I ask how are you going to handle the tricky merging part, like /etc/master.passwd?
Usually that file has entries from 3 sources:
 - From the Base system, which might change between releases
 - From installed ports
 - Manually created entries.

Also, quite often entries from the base system are changed manually, think of root's/toor's password. Are such cases going to be dealt with properly between upgrades, including self-built-and-packaged base systems? Currently it can be a PITA with mergemaster to handle things like master.passwd properly between upgrades, automation so far wasn't famous on doing it properly.

Another thing is, there are a couple of parts of the base system where we add or remove features using knobs, and those take effect at multiple places. Like if I want to have wireless support, there's a bunch of userland utilities being built, and (the important part) some utilities are going to be built differently, like ifconfig. Is handling such features implemented properly by packaging base? We still have to be able to switch between different builds using the new tools.

Another thing is, sometimes when upgrading systems, to make things easier, I deploy the new major version of base, leave old libs/stuff in there till I rebuild and upgrade the packages installed, and after that remove the old libs (rm-old-libs target IIRC). The reason for this, for smaller systems there's usually a build jail which produces packages, and it needs to be upgraded to the new release to make the packages for it, so it's a bit of catch-22, and running rm-old-libs late just solved the issue. Is such a functionality still supported during upgrades? That is, upgrading base systems first in a way that old packages are still functional?

It's a very big projects, with lots of corner cases and difficult issues to tackle, I really appreciate your effort on this.

Best regards,




freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to