jmq/prt-get
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

upload a discussion of the i3 softdeps test

Browse Source
This commit is contained in:
John McQuah 2023-08-25 10:00:19 -04:00
parent 91632a574d
commit 5ee692a858
1 changed files with 90 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
doc/i3-softdeps.md Normal file
View File

@ -0,0 +1,90 @@
# Followup on installing i3 with the softdeps-aware fork of prt-get
## (was Re: prt-get nicetohave)
## 2023-08-25
The "Optional" metadata field took a while to achieve widespread use.
In its early years, there was a strong preference for inflexible
Pkgfiles, whose build() functions contain no branching logic to
customize the build for the host machine. While there often was
some branching logic hidden inside the autotools ./configure script,
the CRUX forerunners of today's proponents of Nix-style "reproducible
builds" might have opted to bypass those tests, using command-line
switches to hard-code the desired defaults [1].
One side effect of hard-coding the configure options in each port is that
it encourages a proliferation of duplicate ports, each with its own
particular combination of configure options. The portdb becomes unwieldy
to manage, navigate, and keep up-to-date, even though each individual port
in the collection is as KISS as possible.
The example perhaps most familiar to recent users of CRUX is the pair of
ports harfbuzz and harfbuzz-icu, which differed from each other only in
the configuration option that enables linking to icu. A port that depends
on the icu-linked harfbuzz would list harfbuzz-icu among its dependencies,
while a port that did not require such linking would only list harfbuzz.
Such dups in the portdb, all using the same upstream tarball, inevitably
have overlapping footprints, and it becomes impossible to avoid filesystem
collisions if a user running 'prt-get depinst foo' triggers an attempt to
pkgadd a variant of an already-installed port. Once the set of installed
ports is sufficiently diverse, maintaining prt-get.aliases so as to avoid
such collisions becomes an impossible task.
Nix (and GoboLinux even earlier) solves the overlapping footprint problem
by giving each package its own distinct place in the filesystem. This
solution is arguably very faithful to the historical CRUX preference for
rigid Pkgfiles, offering a one-to-one correspondence between a repository
of non-fluid ports, and the filesystem where built packages are unpacked.
But CRUX was reluctant to impose an additional layer of complexity on top
of the Filesystem Hierarchy Standard, and so the Nix and GoboLinux solution
never gained serious consideration in the CRUX community.
As the last vestige of a historical preference for non-fluid ports,
harfbuzz and harfbuzz-icu persisted alongside each other until surprisingly
recently, only getting merged into one fluid port in November 2021 (commit
b2e30dbf8c96e03f4fe4b39b1e5ffbecd8372787). This merge allowed users to
simplify prt-get.aliases, removing "harfbuzz-icu: harfbuzz" (if they had
ever added such an entry to avoid filesystem collisions).
Equipping prt-get with softdeps awareness is just letting our tools evolve
to match the trend toward fluid Pkgfiles (FS#1576). If the new prt-get
capabilities are deemed to violate the CRUX Mantra [2], then the same
criticism can be leveled against fluid Pkgfiles. Such criticisms were in
fact expressed (by Anton most stridently, and by Tilman and Juergen in a
gentler tone) during the discussions of USE flags and "prt-get nicetohave"
[3,4]. But the resistance to fluid Pkgfiles has diminished over the years,
to such an extent that nobody has seriously proposed solving the `prt-get
depinst i3` failure [5] by making i3 depend on the duplicate port
libxkbcommon-x11 (which would differ from libxkbcommon only by hard-coding
the meson option '-D enable-x11' and by listing xkeyboard-config as a hard
dependency).
A duplicate port of libxkbcommon is indeed a KISS solution, yet its absence
in the discussion is a clear indication that we aren't going back to
non-fluid Pkgfiles anytime soon. So either our Pkgfiles have irrevocably
become "just a bit" more complex (and therefore no longer "simple"), or
they are in fact the simplest way to accommodate the modern software
landscape. In the latter case, a KISS objection to any new logic in prt-get
is not very plausible. In the former case, it could be argued that two
wrongs don't make a right, and the trend away from KISS Pkgfiles does not
justify making prt-get "just a bit" more complex. But then we would have an
awkward mismatch between the capabilities of prt-get, and the ports that it
has to handle. This mismatch is only a slight annoyance at present (the
experienced users that make up CRUX's target audience can troubleshoot the
build failure [5] relatively quickly), but if it threatens to become more
annoying in the near future, then adding new logic to prt-get is something
worth considering.
[1] It should be noted that the autotools ./configure script (or its
meson or cmake counterpart) might not actually expose all compile-time
options via command-line switches. Hence some testing of the host
environment is unavoidable, unless the port maintainer performs substantial
downstream patching of the source tree.
[2] We don't want to prepare for all necessities and build a complex system
which in 90% of all cases is overkill ... making something "just a bit"
more complex isn't "simple" anymore. (https://crux.nu/Main/Mantra)
[3] https://lists.crux.nu/pipermail/crux-devel/2006-August/001912.html
[4] https://lists.crux.nu/pipermail/crux-devel/2008-May/003366.html
[5] https://libera.irclog.whitequark.org/crux/2023-08-21 (16:36)