00:11 <farkuhar> In https://git.crux.nu/ports/core/issues/4 stenur makes an oblique reference to deep42thought's post-sync hooks (which ukky has kept alive), but stenur's method would defer the application of local patches until the pkgmk step, so that the original repos are not corrupted if a patch no longer applies cleanly.

00:13 <farkuhar> At the end of that ticket, stenur resurrects a complaint reported earlier by Vitaly, where prt-get deviated from pkgmk in parsing the same input. https://lists.crux.nu/archives/list/crux-devel@lists.crux.nu/thread/BNW2BYKMQ5FJSJ3UKZ4KZVXSRVE7U4YW/

00:18 <farkuhar> stenur's idea for the long term is to have prt-get delegate to pkgmk all processing of Pkgfiles (and pkgmk.conf?), so that no discrepancy like the one Vitaly reported could ever arise. But spawning a new shell to obtain the necessary variables for each port in the active repos? That would be an expensive proposition; the slowdown would be noticeable even on modern hardware.

04:51 <brian|lfs> waves

11:58 <farkuhar> The upstream dcron maintainer gave us inconsistent documentation of the new flag introduced in v4.6 (it can't be -L which is already in use): https://github.com/ptchinster/dcron/commit/ce7ddfa552cd948e8c87fb2a25b4cf65f5b216c8

11:59 <farkuhar> When we bump the version in CRUX, we ought to patch the man-page, unless upstream fixes it sooner.

12:14 <farkuhar> personal pet peeve about CLI flags in man-pages: when the hyphen is not marked up as \- but instead as a bare - then some terminals refuse to render it, forcing the user to infer the presence of an invisible hyphen.

12:26 <farkuhar> quick and dirty attempt at cleaning up the crond.8 provided in the v4.6 tarball: https://dpaste.com/9VM2Y6Z83

13:47 <farkuhar> ppetrov^ and lavaball over in #crux-social would accuse me of shouting into the void, by raising these issues in a venue where they are less likely to be acted upon. In the case of dcron, my flippant response is that I don't have a github account (and am not inclined to open one just to file a bug report).

13:50 <farkuhar> But a similar accusation could be leveled at CRUX users who maintain a private overlay in the manner suggested by stenur (or deep42thought before him). By keeping patchsets away from wider scrutiny, these private overlays deprive the official CRUX maintainers of valuable feedback that might make the official ports better.

13:53 <farkuhar> Hence Tim's reaction to FS#1576 (flexible footprint check), where he pushed back against the proliferation of dups in the portdb, preferring instead a collection of "fluid Pkgfiles" that can suit all use-cases.

14:00 <farkuhar> I don't mind the proliferation of dups myself. The sheer variety of configurations demonstrates the ingenuity of CRUX users to adapt the distribution as they see fit. A first-time CRUX user can compare the different styles of building software, learning more from the current portdb diversity than from studying only a slimmed-down set of official repos.

14:30 <farkuhar> One of the earlier attempts at making Pkgfiles more flexible was heidi's suggestion of Gentoo-style USE flags, https://lists.crux.nu/archives/list/crux@lists.crux.nu/thread/32JWFJRJBMKMYX5MONUGGIT3G2MD7TZS/ The transition from pipermail to hyperkitty seems to have resulted in some data loss, because I can no longer find Anton's strongly-worded reply, featuring the phrase "ghastly as hell".

14:40 <farkuhar> In Gitea #4 stenur wishes for the hard and soft dependencies to be promoted to actual shell variables, not comments, so that they can be overwritten by the files in his new $PKGMK_OVERLAY_DIR. I worry that this promotion would encourage future versions of pkgmk to become encumbered with dependency-resolution logic (Per demonstrated back in 2004 how it could be done in bash). The current separation of concerns (pkgmk vs. prt-get) is a feature, not a bug.

14:45 <farkuhar> The introduction of the "Optional" field itself faced some opposition from jue, who in May 2008 called it "not really maintainable, cause the maintainer isn't able to test all the possible options a program is providing". In a way, stenur's overlay idea would help distribute the maintenance burden among the wider CRUX community, allowing for the official Pkgfiles to be inflexible and all the variants to be sequestered in private overlays.

14:50 <farkuhar> Anton's strongly-worded reply to heidi in August 2006 singles out Pkgfiles as the "really valuable thing in CRUX." If they are not kept "as KISS as possible, ... then it's not CRUX anymore." Stupid-simple Pkgfiles are entirely compatible with stenur's overlay proposal, but then pkgmk can no longer remain "as KISS as possible." The complexity has to go somewhere!

15:20 <farkuhar> Vitaly's August 2016 thread https://lists.crux.nu/archives/list/crux-devel@lists.crux.nu/thread/BNW2BYKMQ5FJSJ3UKZ4KZVXSRVE7U4YW/ hints at one option for reducing the confusion that stems from a naive application of "anything not prohibited is allowed". We could simply revise the man-pages Pkgfile(5), pkgmk.conf(5) and prt-get(8) so that users are better informed about which operations involve prt-get inspecting a file without spawning a shell.

15:39 <farkuhar> Heh, if you want a stupid-simple pkgmk you can take inspiration from upkgmk by therealfun. In about 100 lines of bash therealfun offers a tool that "does one thing and does it well." But even this minimal shell script, if spawned hundreds of times to populate the database that prt-get uses in its repo search operations, would soon incur a greater cost than the popen(3) approach that Vitaly finds problematic.

17:25 <farkuhar> At the time of Vitaly's August 2016 thread we didn't yet have a Pkgfile man-page, which only got written for CRUX 3.7 when the renaming feature was introduced. The man-page does provide some indication that prt-get will scan the header fields, but it could be spelled out more clearly that some of the uncommented lines are parsed too, which could cause problems if too many bashisms are employed.

21:06 <ppetrov^> hey farkuhar , i read the log, interesting things you brought up. I was too busy today to follow, but i am interested in how things develop

21:06 <ppetrov^> ah, and I don't accuse you of anything

21:06 <ppetrov^> :P