Arrow of time
Arrow of time

Using pkgng in real life

Share Tweet Share

I have been using pkgng on a few machines now and I'd like to share some thoughts about how it …

I have been using pkgng on a few machines now and I'd like to share some thoughts about how it behaves in real-world situations. Overall, I'm very happy with it and it's immensely better than what we had before. There are some rough edges which need to be solved but those are mostly a property of the ports system itself rather than pkgng.

I'm practically ecstatic about pkgng for one huge reason: no more waiting for ports to compile. Having source-based ports is all fine and well but all that time compiling ports is subtracted from the time the server(s) would perform some actually useful work. After all, servers exist to do some work, not to be waited on while compiling. The same goes for me: I don't want to wait for ports anymore.

I'm happy to say that pkgng pretty seamlessly interacts with the classical ports tree (by adding WITH_PKGNG=1 in /etc/make.conf). I can use most of the pre-built packages, but there are some ports which I absolutely need to compile with non-default options, and those I can compile and install the old-fashioned way. Such ports will automagically be registered with the pkgng package database.

This works until there's a need to upgrade such a port, and I don't really know right now how it will behave in the future. I suspect I will have to be very careful not to upgrade my manually-compiled ports with the default ones.

The recursive upgrade mechanism of pkgng is very powerful and really helps a lot. I had a machine which hasn't really been maintained for years, and I easily converted it to pkgng (using pkg2ng) and used the pkgng's dependancy and recursive upgrade algorithms to install new versions of packages. This worked mostly seamlessly, but there are some corner-case combinations of port/package versions between the "old way" of doing things and the "new way" which slightly confuse pkgng and require manual intervention by removing the old package and installing a new version of it.

There is also the case of replacing a package with another one, which is most recently exposed in the pkg-config <-> pkgconfig fuckup (and yes, it cannot be denied that whole transition was generally a major fuckup regardless of pkgng), which needs to be done manually with "pkg set -o devel/pkg-config:devel/pkgconf ; pkg install -fR pkgconf".

The only major shortcomings of pkgng can be traced to the way ports themselves work. Because they lack the Debian's intelligent "provides/depends/replaces" mechanism for package relationships, it is, for example, practically impossible to install a fcgid-based PHP stack with Apache-worker right now purely with pkgng (but on the other hand it's trivial to do it with lighttpd and other web servers with built-in fastcgi modules). The dependancies are rigid and every Apache module, including mod_fcgid, depends on the default apache package, with its prefork MPM. This can be solved e.g. by installing the apache-worker package and then manually compiling the www/mod_fcgid port. There are numerous other examples of such situations, but they will have to be solved at their roots: the ports tree.

#1 Re: Using pkgng in real life

Added on 2012-09-03T12:18 by vermaden
PKGng is a great step/improvement for current situation. But before PKGng You also did not had to compile whenever You wanted to update a port, there is a pkg_upgrade from bsdadmintools that did that long before PKGng: Regards, vermaden

#2 Re: Using pkgng in real life

Added on 2012-09-03T13:05 by Ivan Voras

Anyone thinking that the processes described in this forum post are easier than pkgng is of course welcome to continue using them ;) Aside from small updates to the utilities to use the new package database, nothing will change for them.

#3 Re: Using pkgng in real life

Added on 2012-09-03T15:09 by vermaden
PNGng is a solution for the FreeBSD packages problem and I encourage everyone to use it, but from what I know it will not be the default way for packages even in upcoming 9.1-RELEASE (correct me if I am wrong). That forum post was a workaround when PKGng was not available and may be still handy on systems what were not migrated to PKGng.

#4 Re: Using pkgng in real life

Added on 2013-03-11T14:22 by Fred R

Well, binary package management is only possible if using splitted packages.

Ex. 1 source package gives many binary packages, and then you can pick up the required sub-packages, simulating what compilation with flags may have produced.

Life's not easy, as it results in a total nightmare the Debian Repos are full of pacakages...

comments powered by Disqus