01:51 <jaeger> oops, looks like the kmod compression changes got eaten in the update

01:52 <jaeger> unless meson enables them by default

01:54 <jaeger> Looks like it does, false alarm

11:19 <farkuhar> In all the years since tilman and jw added support for INSTALL rules in pkgadd.conf, the db_add_pkg function has remained oblivious to them, resulting in a pkgdb that might contain entries with no corresponding file on disk. I asked yesterday in #crux-social: if the fix were as easy as https://0x0.st/8Te-.patch , why was this omission left unpatched for so long?

11:23 <farkuhar> One of the first changes I made in prt-utils was to add a workaround in prtcheckmissing, so that these spurious entries in the pkgdb would not be flagged as missing (having been blocked from installation by a user's own "INSTALL NO" rule). Lately I noticed other prt-utils scripts that could benefit from similar workarounds, and I asked: why not stop the problem at its source (pkgadd committing erroneous entries to the pkgdb)?

11:30 <farkuhar> The patch above should be easier to test, compared to my proposed fix for FS#1074 (altering the function signature of db_rm_pkg to better respect "UPGRADE NO" rules). Testing the latter task is slightly more convoluted, requiring the old and new packages to have footprint differences precisely where an UPGRADE NO rule would apply.

11:36 <farkuhar> As for FS#15 (symlink handling), I'm still working on improving the method for detecting directories. The current method is not robust enough to respect symlinks, resulting in runtime errors (but eventually a successful upgrade) with my current prototype.

14:41 <jaeger> I think the simple answer is nobody has really actively looked after that code for a long time

14:50 <farkuhar> One downside of encumbering the prt-utils scripts with workarounds for spurious entries in the pkgdb, is that the user might have edited pkgadd.conf *after* installing a package, and then the prt-utils script would be referring to a config that wasn't in effect when the package was added. Better to keep the db tidy in the first place, and then we don't have multiple tools parsing the same config.

14:52 <farkuhar> darfo's core issue #8 highlights another instance where we allowed the same config file to govern the operation of different tools (pkgmk and prt-get), resulting in discrepancies if the user defined PKGMK_PACKAGE_DIR in terms of bashisms that prt-get doesn't grok.

15:12 <farkuhar> So in darfo's issue #8 I suggested that pkgmk serve as the Single Point Of Truth (SPOT) for interpreting its config file, and prt-get would have no business inspecting that file itself. Similarly https://0x0.st/8Te-.patch would make the pkgdb a SPOT, so that none of the prt-utils scripts would need to know about pkgadd.conf rules when reading the pkgdb.