Intro:
FreeBSD has implemented a new packaging system called pkg2ng. While that is great for a number of reasons, like allowing commercial companies to now have their own remote repositories or even better faster update times, we still have 1 issue. We would like to also keep the most powerful feature of FreeBSD, the custom port build options we like on our custom ports build.
Ideally what we would like to do then, since FreeBSD now stuffs binary installs and ports collection installs in same SQLite database for pkg2ng, is take advantage of updating with binaries first, then update our custom port builds as well. A big danger we face, is if we just do a normal “pkg upgrade”, we could effectively loose all our custom options in certain ports collection builds. So let’s talk about a way that we can have best of both worlds.
Pre-requisites:
I assume you are running at least FreeBSD 10, and using pkg2ng for package management, and portmaster for port upgrades. Also let us take a custom realistic scenario, let say we want to run alpine with custom options for maildir patch support, also we want to install apache22-itk-mpm, with custom modules built into apache, as well we want to use the new mariadb instead of MySQL for database.
So for this scenario we are not going to want to let binaries touch anything building MySQL, as it will install real MySQL. We also do not want binaries upgrading our apache modules as it will try to install regular apache, so let’s begin.
pkg install apache22-itk-mpm mariadb55-client mariadb55-server cd /usr/ports/mail/alpine; make install; pkg lock alpine cd /usr/ports/www/mod_auth_mysql_another; make install; pkg lock ap22-mod_auth_mysql_another cd /usr/ports/www/mod_geoip2; make install; pkg lock ap22-mod_geoip2 cd /usr/ports/www/mod_perl2; make install; pkg lock ap22-mod_perl2 cd /usr/ports/www/mod_rpaf2; make install; pkg lock ap22-mod_rpaf2 (enable apache module in make config below) cd /usr/ports/lang/php55; make config;make install; pkg lock php55 pkg install php55-extensions pkg install php55-mysql (this is fine as binary since it uses custom MySQL build)
OK Great, now let’s see how we can upgrade for now on.
pkg version -v (see what ports out of date) pkg upgrade (upgrade binary ports first) locked (alias locked='pkg info -ak|grep yes')( check locked ports to unlock for portmaster and update list to unlock/lock below ) (ADD ANY PACKAGES MISSING HERE FROM "locked" COMMAND - unlock ports) pkg unlock alpine; pkg unlock p5-DBD-mysql; pkg unlock ap22-mod_auth_mysql_another; pkg unlock ap22-mod_geoip2; pkg unlock ap22-mod_perl2; pkg unlock ap22-mod_rpaf2; pkg unlock php55 portmaster -adG (upgrade ports) (ADD ANY PACKAGES MISSING HERE FROM "locked" COMMAND - lock ports back) pkg lock alpine; pkg lock p5-DBD-mysql; pkg lock ap22-mod_auth_mysql_another; pkg lock ap22-mod_geoip2; pkg lock ap22-mod_perl2; pkg lock ap22-mod_rpaf2; pkg lock php55 pkg clean
There we have it, now we can get fastest build times as possible, first upgrading binaries, and then our custom ports. Locking packages is what prevents “pkg upgrade” from doing bad things to our custom ports. Of course we need to unlock them after to run portmaster on them. The sad part in this is we have to keep track of what packages to lock and unlock all the time for upgrade purposes. I have opened this issue: https://github.com/freebsd/pkg/issues/744
So if developers get around to adding this new feature to pkg2ng, it could make our life simpler, for now any time you lock a package, just update your upgrade notes, I normally toss it into /etc/motd for easy access.
Till next time, happy FreeBSD 10!
Dan.
Good post, and I totally agree, even though I tend to instal everything from ports anyway!
Instead of using the lock method, how about if pkg upgrade first checks to see if an option file for a port exists, and if so, calls portupgrade (or whatever) instead.
I’m not familiar with portupgrade, but I’d guess you’d call it as required, set to ignore dependencies – letting pkg deal with that and then recall portupgrade as and when necessary.
I agree that would be a better solution. When we run “pkg version -v”, it is actually checking against ports as well for any later versions. “pkg upgrade” will actually inform you about changed options if package is not locked, would be great if this check left the port alone completely 🙂
I would like to say, it is nice to not have to wait as long for upgrades if they compile ports with default options every week, people with a lot of servers will like this. Hardcore people with just a few servers, will prefer ports I am sure 🙂