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
done.
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:
https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase
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,
Gergely
[1]
https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html
Thanks.
Glen
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
