<darfo>
I'm a Gentoo refugee. For me the adjustability of Gentoo became a negative. I recently looked at an ebuild and it had no recognizable Linux comands in it (make, mkdir, etc). Arch seem headed in the same direction. The simplicity of CRUX was appealing combined with a the small amount of reading needed to write my on Pkgfiles.
dlcusa has quit [Remote host closed the connection]
dlcusa has joined #crux
<darfo>
Regarding Vitaly's observation I regard that as a failing in prt-get. pkgmk predates prt-get and is a Bash script. I never knew about prt-get when I started learning to write Pkgfile's. It was easy to read pkgmk and see that it sourced pkgmk.conf and the Pkgfile. So of course they could contain bashisms.
<darfo>
the popen() is called with eval PKGMK_PACKAGE_DIR="/crux/packages/$HOSTNAME" && echo $PKGMK_PACKAGE_DIR
<darfo>
that could be changed to fork() bash -c <that string>
<darfo>
or maybe not. All the C++ I've learned has come mainly from reading prt-get source to discover that it calls ldconfig after a successful pkgmk :)
<farkuhar>
darfo: Compare my Perl solution https://git.sdf.org/jmq/Documentation/src/branch/master/scripts/prt-auf#L931-L945 against the getPkgmkSettingFromFile function in installtransaction.cpp; you'll see I went with a full sourcing of pkgmk.conf rather than just the one line where the definition finally appears, to guard against the possibility that the user employs multiple lines of bash to define the variable.
<farkuhar>
I never bothered to translate that logic back to C++ when maintaining my forked prt-get, because jw's original design is good enough in most cases. It takes a special deviousness like Vitaly's to trigger the parsing mismatch. The simplest solution is to update one of the man-pages to discourage convoluted definitions of PKGMK_PACKAGE_DIR in terms of nested command substitutions or other hackery.
<darfo>
ooh, you're right. fork() of that string won't do it since the other variable aren't set.
<darfo>
pkmgk sources the Pkgfile before pkgmk.conf
<darfo>
I though deviousness was a requirement to get full use of CRUX :)
<darfo>
s /deviousness/inventiveness/
<darfo>
omg. a rabbit hole. vintage systems at sdf.org. Now I know I'm vintage. I've worked on one of those.
<r0ni>
sdf.org is neat and cool
<darfo>
I mispoke. It is pkgadd that invokes ldconfig, not prt-get. I only looked at prt-get when trying to figure out what was invoking ldconfig on prt-get update.
tilman has quit [Ping timeout: 260 seconds]
tilman has joined #crux
brian|lfs has quit [Quit: Leaving]
brian|lfs has joined #crux
brian|lfs has quit [Client Quit]
farkuhar has quit [Ping timeout: 244 seconds]
<crash_>
jaeger: Thanks i will test the updated 3.7 iso on my ventoy stick :)
ppetrov^ has joined #crux
lavaball has joined #crux
SiFuh has joined #crux
farkuhar has joined #crux
<farkuhar>
darfo: You inspired me to look for even more devious ways to break prt-get's method of obtaining the value of PKGMK_PACKAGE_DIR. Here's one, https://0x0.st/8KHV.conf
<farkuhar>
This configuration would also break my Perl rewrite, which uses dummy values for 'name' 'version' and 'release' in an initial digestion of the full pkgmk.conf, only later substituting the actual values obtained from the Pkgfile.
ppetrov^ has quit [Quit: Leaving]
joe9 has joined #crux
<joe9>
anyone using freeswitch on crux? I could not find any port of it in the ports browser too.
ppetrov^ has joined #crux
<darfo>
farkuhar: there is already a Single Point of Truth for pkgmk.conf - bash. I don't think pkgmk needs another flag since it only uses bash to access the contents of pkgmk.conf
<darfo>
the more I look at prt-get installtransaction.cpp the more convinced I am that fork() with bash -c '. <Pkgfile>;. /etc/pkgmk.conf; echo $PKGMK_PACKAGE_DIR' would put prt-get on the same basis as pkgmk.
<darfo>
could clean out some of the logic in the subsequent in the fgets() too
<darfo>
i suppose there could be a similar solution for other languages to use bash for the contents
<farkuhar>
darfo's solution would avoid the mismatch between what pkgmk and other tools regard as the true value for PKGMK_PACKAGE_DIR, but at the cost of bringing those other tools down to the level of operating "one port at a time". The higher-level tools are meant to have awareness of the active port collections all together, which normally should allow some efficiency gains by sending pkgmk.conf through a *single* run of bash.
<farkuhar>
If the only way to ensure absolutely zero breakage is to spin up a separate bash process for every port in the active collections, then you might as well go with Per's March 2004 extension of pkgutils, putting the dependency resolution logic into pkgmk itself.
<farkuhar>
The oldfiles script in prt-utils is another tool that relies on the user not being overly creative when defining the shared package dir. It's possible to write a pkgmk.conf that results in shared package dirs, which oldfiles in its current form would be unable to locate.
<joe9>
might as well use rc instead of bash.
<farkuhar>
Here's another variation on the previous example: https://0x0.st/8K8A.conf Even more paradoxical, because it uses prt-get to define a variable that prt-get itself will load incorrectly!
joe9 has quit [Quit: leaving]
maledictium has quit [Ping timeout: 244 seconds]
<farkuhar>
Accepting that we want the efficiency gains from the current design of prt-get, maybe the best workaround for now is to update the man-page so that the user is aware of such fragile configurations, and can avoid them when deciding where to save the built packages.
<farkuhar>
It's actually still an untested assumption that the current design is significantly more efficient than darfo's suggestion to spin up a separate bash process for each port. Maybe someone should run a head-to-head comparison, seeing how much slowdown is incurred when all those bash processes are launched to obtain all the (possibly different) values of PKGMK_PACKAGE_DIR needed for a prt-get install transaction.
<farkuhar>
darfo correctly points out that pkgmk came before prt-get, but that doesn't stop us from questioning whether Per established the best precedent for how the global config should be handled. It always struck me as odd that pkgmk sourced Pkgfile first, and then the file in /etc. How "global" can the latter config be, if it relies on port-specific variables being defined?
<farkuhar>
Perhaps a more robust design would be to have /etc/pkgmk.conf consist of bash *functions*, whose arguments can be defined later. The parsing order could be instead: source /etc/pkgmk.conf, source ./Pkgfile, and then run the new bash functions to obtain the value of PKGMK_PACKAGE_DIR.
<farkuhar>
Under such a design, you'd get the efficiency advantage of reading /etc/pkgmk.conf *once* before processing multiple ports (as high-level tools like prt-get would be expected to do).
<farkuhar>
No performance penalty would be inflicted on pkgmk by this redesign; the use of bash functions is not significantly slower than parameter expansion for this purpose.
<darfo>
so the high-level tool would run the bash function for each port? Where would it get this bash? It is easy enough to do what I proposed and echo all the PKGMK* variables to obtain all them from one bash process.
<darfo>
or does it just elminate sourcing pkgmk.conf multiple times?
<farkuhar>
If the high-level tool only ends up having one port as an install target, then yes, one bash process would suffice. But as soon as an install transaction starts to involve more than one port, each of which could have its own value of PKGMK_PACKAGE_DIR using trickery like https://0x0.st/8K8A.conf , then you need as many bash processes as installtransaction targets.
<darfo>
the pkgadd that prt-get install runs is a huge task (I/O) compared to what prt-get incurs to obtain those values. The savings will minimal and IMO not worth the added complexity.
<darfo>
s/will minimal/will be minimal/
<darfo>
These are some thorny issues. I've often had to resort to brute force to interface to some of the data that is easy in Perl but harder elsewhere. Like the package db.
<darfo>
but the simple fact that I can get info from the package info with grep makes me reluctant to replace it with some kind of formal DB.
<farkuhar>
I'd like to try making a prototype where pkgmk first sources /etc/pkgmk.conf to load some global functions, then sources ./Pkgfile, and finally defines the needed variables for the package building process. This design would scale up better to installtransactions involving multiple ports.
<darfo>
that would produce an interesting metric
<darfo>
still not sure how multiple installs will avoid multiple bash processes with functions. the problem is that each Pkgfile can affect the output of pkgmk.conf.
<farkuhar>
True, you cannot avoid needing a separate bash process for each install target, if you want to be fully robust against user cleverness. The potential speedup of the new design is in being able to pre-load the global definitions from pkgmk.conf, and then read just the Pkgfile for each install target.
<farkuhar>
So the code that affects PKGMK_PACKAGE_DIR is already loaded, and just has to be passed to bash along with whatever values the Pkgfile provides. You're not constantly re-reading pkgmk.conf (which would really only be justified if the file on disk happens to change during the span of a single install transaction).
<darfo>
Can already preload pkgmk.conf. Per didn't need to retain the pkgmk.conf but the high-level tools could. And then resolve the values for each Pkgfile, to be fully robust for user cleverness.
<darfo>
:)
<darfo>
gotta go be chauffeur. cheers.
<farkuhar>
Heh, something to try with the current design of our distro tools. Start up a massive build like `prt-get depinst qutebrowser`, make a non-trivial change in pkgmk.conf while one of the ports is being built, and see if the pkgadd command has trouble locating the built package when it finishes compiling.
zorz has joined #crux
ivandi has quit [Quit: WeeChat 4.5.1]
ivandi has joined #crux
<farkuhar>
Reading the current man-page pkgmk.conf(5), I see a number of places where inserting a gentle prohibition on user cleverness might have prevented Vitaly's original discovery. Or if it had reminded users of the working environment when it gets sourced by pkgmk, then maybe prt-get installtransaction.cpp wouldn't have taken the shortcut that led to the mismatch.
<farkuhar>
Imagine an alternate universe where pkgmk.conf(5) flatly rejected the possibility of dynamically-defined values for PKGMK_SOURCE_DIR or PKGMK_PACKAGE_DIR (i.e., defined in terms of Pkgfile variables like 'name' or 'version'), and endorsed instead only constant strings. Vitaly might still have tried to use $HOSTNAME in such a definition, thinking it would clearly be constant across all ports on the build machine.
<farkuhar>
The man-page for pkgmk(8) is not much better, stating merely that /etc/pkgmk.conf is read by pkgmk at startup. Left unmentioned is the tiny but crucial detail that ./Pkgfile is sourced first. It's only by reading the script that a user learns why it's possible for Pkgfile variables to appear in the "global config".
<farkuhar>
Surely jw was aware of these design issues when he wrote installtransaction.cpp. If his new tool was also going to rely on pkgmk.conf, then tightening up the man-page pkgmk.conf(5) to discourage perverse configurations would have been an appropriate task to fold into the release checklist. That way any cleverness could have been suppressed before users configured their systems in an unsupported manner.
ppetrov^ has quit [Remote host closed the connection]
ppetrov^ has joined #crux
<farkuhar>
System-wide unsupported configuration is one thing, but it's also possible to cause trouble with just a single port. Following the maxim "anything not prohibited is allowed", you could write PKGMK_PACKAGE_DIR=$(mktemp -d --tmpdir mypackages.XXX) in the opening part of the Pkgfile itself, and (assuming the variable is not reset to a saner value by the global config) the built package would appear in a location unguessable by prt-get.
<farkuhar>
I should add a test for that kind of deviousness to the prtverify test suite. Currently prtverify does not complain, when the Pkgfile defines global pkgmk variables like this.
lavaball has quit [Remote host closed the connection]
DesRoin has quit [Quit: WeeChat 4.5.1]
DesRoin has joined #crux
joe9 has joined #crux
zorz has left #crux [#crux]
<darfo>
upgraded vim to latest. now the screen goes reverse video as soon as the cursor is moved. fellback 9.1.1055-1 to vim#9.1.0887-1 and blinding glare ceased.
<darfo>
turns out delete .vimrc got rid of the problem. RIP trusty old .vimrc. See if surgery will revive it. Removing syntax on didn't help.