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

i3-softdeps.md: minor revisions

Browse Source
This commit is contained in:
John McQuah 2023-08-26 17:24:39 -04:00
parent 449c0e0553
commit e97879074b
1 changed files with 70 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

122
doc/i3-softdeps.md
View File

@ -1,27 +1,44 @@
# Followup on installing i3 with the softdeps-aware fork of prt-get # Followup on installing i3 with the softdeps-aware fork of prt-get
## (was Re: prt-get nicetohave) ## (Was: Re: [prt-get nicetohave](https://lists.crux.nu/pipermail/crux/2023-August/007375.html))
## 2023-08-25 ## 2023-08-25
The "Optional" metadata field took a while to achieve widespread use. The "Optional" metadata field stirred up some controversy when first
In its early years, there was a strong preference for inflexible proposed. At the time, it was preferred to write Pkgfiles whose build()
Pkgfiles, whose build() functions contain no branching logic to functions contain no branching logic to customize the build for the host
customize the build for the host machine. While there often was machine. Maintainers would even try to suppress the branching logic hidden
some branching logic hidden inside the autotools ./configure script, inside the autotools ./configure script using command-line switches to
the CRUX forerunners of today's proponents of Nix-style "reproducible hard-code the desired defaults [1]. Peer pressure eventually wore away at
builds" might have opted to bypass those tests, using command-line the resistance to this new metadata field, so it is now in widespread use
switches to hard-code the desired defaults [1]. despite there being no official mandate for contributors to test their ports
under all possible configurations. Whenever a port can adapt to a variety of
use-cases, maintainers try to document that versatility in the "Optional"
field. But our package management tools remain unable to use that data! At
present, it requires a human reading the Pkgfile, for the data in the "Optional"
field to affect the order in which ports are built. Thankfully, sorting with
optional dependencies taken into account is now possible in prt-get itself,
either with the
[softdeps](https://git.crux.nu:82/farkuhar/prt-get/src/branch/softdeps) or the
[mixed-upinst](https://git.crux.nu:82/farkuhar/prt-get/src/branch/mixed-upinst)
branch of the fork by farkuhar.
One side effect of hard-coding the configure options in each port is that Respecting the limitations of a prt-get that only knows about hard dependencies
it encourages a proliferation of duplicate ports, each with its own would entail following the old practice and hard-coding the configure options
particular combination of configure options. The portdb becomes unwieldy in each port. This example of letting our tools dictate how we work (rather
to manage, navigate, and keep up-to-date, even though each individual port than updating the tools to fit a new workflow) would encourage a portdb more
in the collection is as KISS as possible. like the AUR, with a seemingly endless variety of dups that all have
their own particular combination of configure options. Thankfully the
unwieldiness of this prospect was enough to deter maintainers from clinging to
an outmoded interpretation of KISS [3], and they adopted the new norm of
"fluid Pkgfiles" (FS#1576) even as prt-get remained unable to incorporate this
fluidity in its operations.
The example perhaps most familiar to recent users of CRUX is the pair of As recently as November 2021, users of CRUX could still have noticed a remnant
ports harfbuzz and harfbuzz-icu, which differed from each other only in of the historical preference for non-fluid Pkgfiles, illustrated by the
the configuration option that enables linking to icu. A port that depends coexisting pair harfbuzz and harfbuzz-icu. These ports differed from each other
on the icu-linked harfbuzz would list harfbuzz-icu among its dependencies, only in the configuration option that enables linking to icu. A port that
while a port that did not require such linking would only list harfbuzz. 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 Such dups in the portdb, all using the same upstream tarball, inevitably
have overlapping footprints, and it becomes impossible to avoid filesystem have overlapping footprints, and it becomes impossible to avoid filesystem
@ -31,8 +48,8 @@ ports is sufficiently diverse, maintaining prt-get.aliases so as to avoid
such collisions becomes an impossible task. such collisions becomes an impossible task.
Nix (and GoboLinux even earlier) solves the overlapping footprint problem Nix (and GoboLinux even earlier) solves the overlapping footprint problem
by giving each package its own distinct place in the filesystem. This by giving each package its own separate directory in the filesystem. This
solution is arguably very faithful to the historical CRUX preference for solution arguably fits quite well with the historical CRUX preference for
rigid Pkgfiles, offering a one-to-one correspondence between a repository rigid Pkgfiles, offering a one-to-one correspondence between a repository
of non-fluid ports, and the filesystem where built packages are unpacked. 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 But CRUX was reluctant to impose an additional layer of complexity on top
@ -41,39 +58,39 @@ never gained serious consideration in the CRUX community.
As the last vestige of a historical preference for non-fluid ports, As the last vestige of a historical preference for non-fluid ports,
harfbuzz and harfbuzz-icu persisted alongside each other until surprisingly harfbuzz and harfbuzz-icu persisted alongside each other until surprisingly
recently, only getting merged into one fluid port in November 2021 (commit recently, only getting merged into one fluid port with commit
b2e30dbf8c96e03f4fe4b39b1e5ffbecd8372787). This merge allowed users to b2e30dbf8c96e03f4fe4b39b1e5ffbecd8372787. This merge allowed users to
simplify prt-get.aliases, removing `harfbuzz-icu: harfbuzz` (if they had simplify prt-get.aliases, removing `harfbuzz-icu: harfbuzz` (if they had
ever added such an entry to avoid filesystem collisions). ever added such an entry to avoid filesystem collisions).
Equipping prt-get with softdeps awareness is just letting our tools evolve 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 to match the trend toward fluid Pkgfiles. If the new prt-get capabilities
capabilities are deemed to violate the CRUX Mantra [2], then the same are deemed to violate the CRUX Mantra [2], then the same criticism can be
criticism can be leveled against fluid Pkgfiles. Such criticisms were in leveled against fluid Pkgfiles. Such criticisms were in fact expressed
fact expressed (by Anton most stridently, and by Tilman and Juergen in a (by Anton most stridently, and by Tilman and Juergen in a gentler tone)
gentler tone) during the discussions of USE flags and "prt-get nicetohave" during the discussions of USE flags and "prt-get nicetohave" [3,4]. But the
[3,4]. But the resistance to fluid Pkgfiles has diminished over the years, resistance to fluid Pkgfiles has diminished over the years, to such an extent
to such an extent that nobody has seriously proposed solving the `prt-get that nobody has seriously proposed crafting the dependency graph so that
depinst i3` failure [5] by making i3 depend on the duplicate port `prt-get depinst i3` is impossible to fail [5], say by making i3 depend on a
libxkbcommon-x11 (which would differ from libxkbcommon only by hard-coding duplicate port libxkbcommon-x11 (which would differ from libxkbcommon only by
the meson option '-D enable-x11' and by listing xkeyboard-config as a hard hard-coding the meson option "-D enable-x11" and by listing xkeyboard-config
dependency). as a hard dependency --- similar to how harfbuzz-icu differed from harfbuzz).
A duplicate port of libxkbcommon is indeed a KISS solution, yet its absence A duplicate port of libxkbcommon is indeed a KISS solution, with prt-get in its
in the discussion is a clear indication that we aren't going back to present state. That nobody bothered to propose such a dup is a clear indication
non-fluid Pkgfiles anytime soon. So either our Pkgfiles have irrevocably that we are not going back to non-fluid Pkgfiles anytime soon. So either our
become "just a bit" more complex (and therefore no longer "simple"), or Pkgfiles have irrevocably become "just a bit" more complex (and therefore no
they are in fact the simplest way to accommodate the modern software longer "simple"), or they are in fact the simplest way to accommodate the modern
landscape. In the latter case, a KISS objection to any new logic in prt-get software landscape. In the latter case, a KISS objection to any new logic in
is not very plausible. In the former case, it could be argued that two prt-get is hypocritical. 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 wrongs do not 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 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 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 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 experienced users that make up the CRUX target audience can usually diagnose
build failure [5] relatively quickly), but if it threatens to become more the problem themselves if they encounter a build failure like [5]), but before the
annoying in the near future, then adding new logic to prt-get is something software landscape becomes even more convoluted and such build failures harder
worth considering. to avoid, we should have the discussion on adding new logic to prt-get.
[1] It should be noted that the autotools ./configure script (or its [1] It should be noted that the autotools ./configure script (or its
meson or cmake counterpart) might not actually expose all compile-time meson or cmake counterpart) might not actually expose all compile-time
@ -81,12 +98,13 @@ options via command-line switches. Hence some testing of the host
environment is unavoidable, unless the port maintainer performs substantial environment is unavoidable, unless the port maintainer performs substantial
downstream patching of the source tree. downstream patching of the source tree.
[2] We don't want to prepare for all necessities and build a complex system [2] We do not want to prepare for all necessities and build a complex system
which in 90% of all cases is overkill ... making something "just a bit" which in 90% of all cases is overkill ... making something "just a bit"
more complex isn't "simple" anymore. (https://crux.nu/Main/Mantra) more complex is not "simple" anymore. (https://crux.nu/Main/Mantra)
[3] https://lists.crux.nu/pipermail/crux-devel/2006-August/001912.html [3] https://lists.crux.nu/pipermail/crux-devel/2006-August/001912.html
[4] https://lists.crux.nu/pipermail/crux-devel/2008-May/003366.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) [5] The possibility of this command failing was first noted by jaeger in
https://libera.irclog.whitequark.org/crux/2023-08-21 (16:36)