[crux-devel] prt-get design issue

Vitaly Sinilin vs at kp4.ru
Sun Aug 14 07:34:56 UTC 2016


Hi,

Although CRUX IMHO is much more flexible in terms of configuration
than other distros I seem to face the limits of the freedom it
provides ;-)

Tl;dr: the root cause of all difficulties I underwent was prt-get
peeking into the pkgmk.conf file and I would like to discuss a solution
for this.


1)

What I was trying to do is to have each CRUX box storing its packages
in its own directory on an NFS server named after the hostname. So I
changed pkgmk.conf like

   PKGMK_PACKAGE_DIR="/crux/packages/$HOSTNAME"

And pkgmk seemed to work well. But prt-get didn't. It was calling pkgmk,
pkgmk was building the package, but prt-get was unable to install it.

It turned out that prt-get had its own opinion regarding directory
where packages are stored. Long story short, prt-get uses popen(3) to
evaluate pkgmk.conf and popen() passes the command to /bin/sh which is
not a symlink to /bin/bash anymore (and $HOSTNAME is a bashism).

Yes, such configuration works fine on CRUX 2.8.

Yes, I know that I can just probably use `hostname` (I've never tried
it though), but it's not the point. The point is that two independent
interpreters (I mean pkgmk itself and prt-get) of pkgmk.conf exist
and special care from developers is required to keep them in sync.


2)

I usually use something like this in prt-get.conf of my boxes

   makecommand sudo -H -u pkgmk /usr/bin/fakeroot /usr/bin/pkgmk

and PKGMK_PACKAGE_DIR is only writable by the pkgmk user. What I don't
like in this configuration is that to build a package privately as an
unprivileged user I have to use some other pkgmk.conf file, what is not
really bad per se, but passing this file from command line every time
is a pain and I have to use some one-line wrapper named like mypkgmk.

Recently I realized that this approach can be simplified.
/etc/pkgmk.conf could contain a user-friendly configuration like build
everything in $PWD because it is mostly used from command-line and
prt-get can refer to another pkgmk.conf file that noone else is
using. So I changed my prt-get.conf to

   makecommand sudo -H -u pkgmk /usr/bin/fakeroot \
       /usr/bin/pkgmk -cf /etc/pkgmk-system.conf

and got the same problem as in the first story. As you've already
understand prt-get used /etc/pkgmk-system.conf for building the
package, while /etc/pkgmk.conf for installing.


Conclusion

You may say that my configurations are perverse, but on the other
hand nothing in the CRUX documentation states that such configurations
are illegal. So I would say that from the principle of least
astonishment they should work.

If you are allowed to use custom make command you can expect that there
is no other depencencies to the default command (by the way, it is
never mentioned in prt-get(8) and prt-get.conf(5) that prt-get is
peeking into hardcoded(!) /etc/pkgmk.conf).

Obvious solution for this flaw is some kind of interface between
prt-get and pkgmk that will allow the latter to inform the former about
the directory where it will/would place the package.

As a proof-of-concept I added the -dc|--dump-config option into pkgmk
and modified prt-get so it calls $makecommand -dc and analyses its
output instead of /etc/pkgmk.conf.

It fixed both my issues:
1) $HOSTNAME is now expanded by pkgmk itself because --dump-config
   dumps values as they are interpreted by pkgmk (not verbatim values
   from pkgmk.conf);
2) prt-get asks "pkgmk -cf /etc/pkgmk-system.conf" about its
   configuration with the -dc option and gets correct
   PKGMK_PACKAGE_DIR value specified in /etc/pkgmk-system.conf.

As a nice side effect this approach allows source-ing of pkgmk.conf
files. E.g. my /etc/pkgmk-system.conf is the following

   #
   # /etc/pkgmk-system.conf: pkgmk(8) configuration
   #

   . /etc/pkgmk.conf

   PKGMK_SOURCE_DIR="/crux/distfiles"
   PKGMK_PACKAGE_DIR="/crux/packages/$HOSTNAME"

(The interpreter of prt-get-5.19 won't be able to figure out
PKGMK_COMPRESSION_MODE value from this configuration file.)

I know from this mailing list that some people live with their own
tuned versions of CRUX tools and I will probably do too, but as long as
the spoken approach doesn't break any backward compatibility I think it
can be considered for inclusion into the offical CRUX tools.

-- 
Vitaly Sinilin <vs at kp4.ru>



More information about the crux-devel mailing list