02:01 <darfo> Ok. I guess non-core port authors could inform users of important files they might want to protect from updates that aren't directly edited by users but can be altered by package update. I never knew here prt-get kept its locks until they got clobbered.

02:01 <darfo> s/knew here/knew where/

10:17 <farkuhar> As pointed out in #11, prt-get has been stable for some time now. Maybe it wasn't anticipated that prt-get would receive any updates before a new release of CRUX, and so it was deemed harmless to provide an empty lockfile with the port.

10:58 <cruxbot> [core/3.7]: curl: updated to version 8.12.1

11:02 <cruxbot> [core/3.7]: dhcpcd: updated to version 10.2.0

11:23 <farkuhar> `touch $PKG/var/lib/pkg/prt-get.locker` was not added to the Pkgfile until version 5.19.6; prior to that, running `prt-get listlocked` with a nonexistent lock file would return the failure message reported in #11. The update to 5.19.6 refers to FS#434 (which unfortunately does not appear among the notes I was keeping before Flyspray got taken down, otherwise I would share the details of that task).

11:36 <cruxbot> [opt/3.7]: iwd: updated to version 3.4

11:38 <farkuhar> Regarding #8, darfo's patch is essentially the reversal of commit 318a4a0768112deaa12fb323e92c4891f584b17e (2006-09-10, just a few days before prt-get 5.14 was released).

11:43 <farkuhar> The ChangeLog explains this commit as "determine PKGMK_PACKAGE_DIR using fgrep without sourcing pkgmk.conf". Ten years later, Vitaly would observe at least one downside of passing a single grepped line to /bin/sh for evaluation, but his observation didn't immediately inspire a proposal to reverse 318a4a0768112deaa12fb323e92c4891f584b17e.

11:48 <cruxbot> [opt/3.7]: nss: updated to version 3.108

11:55 <farkuhar> Even reverting to the old behaviour of sourcing the entire pkgmk.conf might not be enough to ensure that prt-get is on the same page as pkgmk. Because pkgmk.conf is sourced after the Pkgfile, a user might feel justified to write such definitions as PKGMK_PACKAGE_DIR="/var/packages/$(prt-get printf '%p\n' --filter=$name | head -n 1 | sed 's,.*/,,')", which prt-get will not resolve correctly even with darfo's patch.

12:05 <farkuhar> I opened #5 to address the same problem as darfo's #8, but without trying to accommodate every possible creative definition that might appear in pkgmk.conf. By expanding the documentation to inform users how their custom PKGMK_* definitions are processed, we make it their responsibility to write a config that won't cause problems.

12:11 <farkuhar> Expanded documentation would address what Vitaly in August 2016 called the "principle of least surprise". If we warn users in advance about the configurations that are known to cause discrepancies between pkgmk and prt-get, then they have no reason to be surprised when they try such a configuration and suffer breakage.

12:19 <farkuhar> In FS#1410 (pkgmk support for binary packages), Fun "was trying to understand why people leave CRUX (once they like it)" and beerman offered some reasons, third of which was "they are not helped properly. instead of getting to learn our system tools, you can watch people getting told to use wrapper scripts, *patch prt-get themselves* or whatever." (emphasis added)

12:24 <farkuhar> Maybe the divergent parsing of pkgmk.conf is not enough to drive people away from CRUX, but we can avoid driving them to "patch prt-get themselves" by providing a more comprehensive explanation of our system tools; hence my suggestion in #5 to expand pkgmk.conf(5).

14:14 <darfo> In what usage of prt-get does fgrep over sourcing save any significant time? I still state that prt-get should continue to use the same mechanism that pkgmk uses to obtain values from pkgmk.conf and Pkgfile. Not to do so allows future problems with prt-get when pkgmk is changed.

14:15 <darfo> I'm still not sure why a problem in prt-get becomes pkgmk's problem to solve. pkgmk works as documented.

14:20 <darfo> it was the change of /bin/sh to dash instead of bash that caused prt-get's difficulty. CRUX always ran on bash. The root user's default shell in a fresh install is /bin/bash.

14:21 <darfo> As Vitaly(?) pointed out, it was popen() not fgrep() that caused prt-get to incorrectly resolve PKGMK_PACKAGE_DIR.

15:39 <farkuhar> prt-get before or after 318a4a0768112deaa12fb323e92c4891f584b17e would have trouble obtaining the correct value of PKGMK_PACKAGE_DIR for some configurations, even if /bin/sh were still a symlink to bash. The advantage of a documentation-based solution is that it doesn't require us to anticipate all possible user cleverness; we just have to give firmer guidance on what will work with all the tools that read pkgmk.conf.

15:44 <farkuhar> Fair point, maybe it's not pkgutils that should bear the burden of adapting to a poor design choice by prt-get. But we're stuck with the decision that a config file owned by pkgutils is also influencing prt-get. Note that in #5 I'm not proposing any change to the pkgmk script, just some additional language in the man-page that would explain why certain bash constructs lead to breakage.

15:47 <farkuhar> As for the reasoning behind switching to fgrep after so many versions where the entire pkgmk.conf was being sourced, I don't have first-hand knowledge of the discussions leading up to commit 318a4a0768112deaa12fb323e92c4891f584b17e. But frinnst was involved in those days, so maybe he can recall why that change was made.