<not-my-computer>
Yeah farkuhar maybe. Let me check. But there is a road in Buderim that I think is spelled the first way and pronounced the way I said.
<not-my-computer>
Yeah it says gloss-ster
serpente has quit [Remote host closed the connection]
<not-my-computer>
farkuhar: One of my favorite is the word 'rendezvous' always funny to see the people's faces when they realise how to pronounce it.
not-my-computer has quit [Quit: not-my-computer]
still-not-my-com has joined #crux-social
still-not-my-com has quit [Quit: still-not-my-com]
ppetrov^ has joined #crux-social
<farkuhar>
ppetrov^: Another possible speedup of `ports -u` might be to switch to a different driver. If you're still using httpup for your repo, try setting it up with git or rsync instead, to see if that makes a difference.
<farkuhar>
You can't completely abandon the httpup-repgen step if you want to be listed on the portdb, but you can offer users of your r4-modules repo a faster alternative (once you confirm that git or rsync really is faster).
<farkuhar>
Hmm, if you want to customize the directory where a built package is stored on KISS Linux, you have to tweak the environment variable XDG_CACHE_HOME. Similarly, changing the compression mode requires updating the environment variable KISS_COMPRESS.
<farkuhar>
Environment variables do have the advantage of being more easily accessed in tools that are not themselves bash scripts. So in KISS there would be no possibility of the disagreement pointed out by Vitaly in 2016: pkgmk and prt-get arriving at two different values for PKGMK_PACKAGE_DIR, due to the different ways they parse the same config file.
<farkuhar>
The code that jw gave us is good enough for the most common configurations. But users who follow the adage "anything not prohibited is allowed" can be forgiven for expecting the latter construct (separate package dirs per repo) to work. jw could have just updated the pkgmk.conf man-page to explicitly prohibit such customizations of the variables that govern tools at both the port-level and the
<farkuhar>
entire-repo-level, once he realized the possibility of a divergence in parsing.
<farkuhar>
It's remarkably forward-thinking of KISS to rely on environment variables here, considering that their package manager, written in POSIX-compliant shell, encompasses all functionality from the level of individual ports to the level of entire repos. The fact that they didn't use shell variables (visible only to the kiss script) testifies to an anticipation that other tools might eventually try to
<farkuhar>
reimplement package management in languages other than *sh.
<farkuhar>
In the previous discussion with darfo, I suggested that distro tools needing to access common variables from /etc/pkgmk.conf should agree on a Single Point of Truth (SPOT). Citing the historical priority of pkgmk, and the name of the config file itself, darfo gave an uncontroversial answer: a bash instance spawned in the port directory could serve as the SPOT.
<farkuhar>
The slowdown entailed by having to spawn a new bash instance for each port, in order to guarantee agreement with pkgmk, discouraged jw and sip from employing this strategy in prt-get and pkg-get, respectively. With pkg-get (specifically pkg-repgen), it's easy enough to suppress the erroneous parsing of pkgmk.conf when extracting the value of PKGMK_COMPRESSION_MODE; simply glob for all supported
<farkuhar>
suffixes and you won't miss any entries in the generated PKGREPO.
<farkuhar>
Meanwhile prt-get has fewer built-in defenses against excessively-creative definitions in /etc/pkgmk.conf; by extracting only a single line matching a relatively narrow pattern, and passing that line to popen() for evaluation, prt-get is inadvertently ignoring those other lines that might affect the variable.
<ukky>
farkuhar: conf-file, ideally, should have yes/no/path settings.
<farkuhar>
What jw got right about the prt-get algorithm is the step that strips away leading whitespace. In the pkg-repgen code, a line like ppetrov^s (with leading whitespace before PKGMK_COMPRESSION_MODE=) was being ignored, because it didn't match the narrow regexp that pkg-repgen was looking for. I'll have to add a fix to loosen up that regexp.
<farkuhar>
ukky: pkgmk.conf(5) does inform the user what types are expected for all the variables (mostly boolean or string), but it leaves open the possibility that those values are arrived at by command substitution or other shenanigans. Once the user is aware that the conf-file is interpreted by bash, they can go crazy with the definitions, making the conf-file intelligible to pkgmk but not to prt-get.
<farkuhar>
Hence my initial recommendation: just amend the man-page to discourage creative definitions. Then the user cannot cite "anything not prohibited is allowed" as an excuse.
<ukky>
When pkgmk.conf has non-string settings, it should be properly renamed into /etc/pkgmk.sh, to indicate that it is not just settings, it is a fully-blown complex script.
<farkuhar>
ukky: It's not that the settings themselves aren't strings, it's that the route to determining those strings might be convoluted, spanning multiple lines and involving shell functions defined earlier. What jw's algorithm does is to assume that no such shenanigans are involved, which is a faulty assumption for a setup like https://dpaste.org/XVUBf
<farkuhar>
I agree with ukky's recommendation to adopt a different name for the global config, acknowledging the possibility that users might want to define their settings in terms of shell functions. Constrain the user's creativity to live within the confines of pre-selected shell function names like echo_pkgdir() or echo_compressionmode(), whose arguments---if any---always come in a particular order (name,
<farkuhar>
version, release). Then no matter what language you write your distro tool in, you can always spawn a bash shell, source /etc/pkgmk.sh, and capture the output of these shell functions for subsequent use.
<farkuhar>
The problem with the current design is that bash parameter substitution is the most common way to define the string variables, hence the need to have known values for $name $version and $release *before* sourcing /etc/pkgmk.conf. Whereas if you restricted /etc/pkgmk.sh to defining shell functions, then you can pre-load those definitions *once*, and pass them to bash along with the Pkgfile variables
<farkuhar>
whenever your distro tool needs to resolve a shared variable (PKGMK_PACKAGE_DIR or PKGMK_COMPRESSION_MODE).
<ukky>
farkuhar: what I meant is that even PKGMK_COMPRESSION_MODE="$_USER_DEFINED_PKGMK_COMPRESSION_MODE" should not be used, as 'prt-get' is not a shell script and will fail getting PKGMK_COMPRESSION_MODE value.
<farkuhar>
ukky: Correct, prt-get is not a shell script, but if it wants to peek inside the config file of a program that *is* a bash script, then it has to be designed more defensively to prevent parsing discrepancies.
<farkuhar>
As I see it, jw and sip had a few good options when deciding that prt-get and pkg-get (C++ and Perl, respectively) needed to parse the config file of a bash script. They could have insisted on moving the common settings into a separate file (untouchable by the playfulness permitted to pkgmk config), or they could have revised pkgmk.conf(5) to discourage creative definitions.
<farkuhar>
The third possibility is even more drastic: change the order in which pkgmk loads its global config and its Pkgfile variables, forcing the global config to be written in terms of shell functions, not parameter substitutions. That way, the Single Point Of Truth would remain a bash instance, but with the efficiency of having to load the global config just once, passing those shell functions and the
<farkuhar>
Pkgfile variables to bash, regardless of what language your distro tool is written in.
<zorz>
yo guys... create a channel #pkgmk or #prt-get :P
<farkuhar>
One omission from that first draft is an explicit enumeration of the variables that prt-get tries to obtain from pkgmk.conf. PKGMK_PACKAGE_DIR is implied, yes, but I could have also mentioned PKGMK_COMPRESSION_MODE, now that we'll soon be allowing "zst" among its possible values.
<farkuhar>
Reversing the order in which pkgmk sources its definitions (currently Pkgfile before /etc/pkgmk.conf) wouldn't _force_ the user to employ shell functions in the global config, but it would prevent the user from employing Pkgfile variables the way it's commonly done now. And a global config that's more agnostic regarding Pkgfile variables would be less fragile than what prt-get currently might
<farkuhar>
encounter.
<farkuhar>
Does anyone have their MUA configured to display messages in threaded mode? I'm wondering if it breaks the threading to change the subject line in a reply (apart from adding a prefix "Re:"), while still retaining References: and In-Reply-To:
<ukky>
farkuhar: My MUA does not care for Subject in headers. Only References: and In-Reply-To: are important for threaded mode. 'Re:' in Subject is not required.
<farkuhar>
I realize the behaviour of a threading MUA might not be controlled by any IETF standard, and every MUA might implement threading differently. But if ukky's experience is the common way for threading to be handled, that puts my mind at ease on the matter of editing the Subject line.
<ukky>
farkuhar: It is kind of less important when you reply to mailing list messages. But maybe adding 'Re:' is part of netiquette for person-to-person mail.