Hi Luca, * Luca Boccassi <bluca@debian.org> [2023-06-29 12:49]:
The sole benefit is that one of the two bootstrapping tools in widespread use keeps its internal code a bit 'cleaner' from the point of view of some technically unnecessary and self-imposed design constraints (yes there's 2 more tools as pointed out yesterday, but they appear to be at least under-maintained judging from tracker.d.o).
I believe you are narrowing the focus too much on an implementation
instead of taking the concept into consideration.
If I understand Josch correctly, he is aiming for a fully
declarative way to describe how to setup a Debian system, and I
believe that the idea has a lot of merit. It is also consistent with
a general trend in Debian: just look at d/rules and see how little
actual code a modern debhelper rule script needs; with dh-sequence-*
and other declarative files in debian/, it is often little more than
%:
dh $@
It makes packaging simpler, avoids code duplication and also makes
it much easier for tools like lintian to reason about package
behavior. For instance, good luck coming up with a reliable check to
see if a hand-written d/rules without dh_auto_test properly obeys
the "nocheck" profile.
I don't see how it's worth the risk. This is essentially a problem in the bootstrapping tools, so solving it in the bootstrapping tools is not only the safest approach - worst case scenario, creating a new sid chroot might not work for a couple days, not a big deal given it happens all the time for various reasons as we've seen this week - it's also the right approach.
Josch already made a good analogy that this is "essentially a bootstrapping tools problem" in the same way that dependency resolution is "esssentially a dpkg problem", yet nobody patches dpkg if someone omits "Depends: libbar-dev" in a libfoo-dev which happens to include stuff from bar in its headers. I do concede that we need not limit ourselves to just two options, either have a bootstrapping that works with package dependencies as-is, or have a free-for-all with random and arbitrarily complex code in bootstrapping tools. We could also declare a bootstrapping protocol that always unpacks a specific package (let's call it "first-package"), which may contain additional configuration options to guide the bootstrapping process. We could also teach dpkg to always upgrade that particular package first, as a way to get something like a dist-upgrade script. My point is, Josch raises some interesting points, which we should at least take into consideration and not dismiss them out of hand because bootstrapping is not important for us. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Attachment:
signature.asc
Description: PGP signature