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@kp4.ru>
participants (1)
-
Vitaly Sinilin