Hi Adrian, At 2025-04-21T01:34:56+0300, Adrian Bunk wrote: > On Sun, Apr 20, 2025 at 04:46:52PM -0500, G. Branden Robinson wrote: > > Factual statements about one's run-time dependencies should be as > > decoupled from the details of the set of "Essential" packages as > > possible. One reason is that the identities of the people making > > these decisions are disjoint. Often a package maintainer lacks this > > power; except for dependencies they introduce through operation of > > their maintainer scripts (or Debian add-ons), such run-time > > dependencies are beyond their control. > >... > > While this might sound good in theory, in practice it would be > horrible.
I'm not convinced...yet.
> As an example, libc6 has a preinst script that calls dpkg, sed,
> grep and rm.
A maintainer script that calls `dpkg`, I think, violates the Principle
of Least Astonishment.[1]
> Making these dependencies explicit would be something like
> Pre-Depends: sh, dpkg, sed, grep, coreutils
>
> I would expect that such Pre-Depends cycles between essential packages
> and libc6 will result in broken systems during upgrades.
My impression from watching countless upgrades over the years is that,
when any Essential package is available for upgrade, upgrades performed
by apt launch a full, discrete run of dpkg for each.[3] So the only way
any such cycles could exist is if the Pre-Depends were versioned and the
versionings themselves produced the cycle, in which case there likely
_really is_ a breakage problem: one package or the other needs to delay
its aggressive employment of a newly available feature.
> And then there's the normal time-waste like "the package ships
> a bash-completion file that uses awk, grep, sed and sort - that's
> dependencies on four essential packages".
Hmm. In my opinion bash-completion scripts should produce
"Recommends"-strength dependencies at most; not everybody's going to be
using bash as their interactive shell, and completion matters only for
interactive shells.
That said, I haven't looked but would not be surprised if
bash-completion scripts make extremely aggressive assumptions about
what's available on the system. That is, they seldom if ever look
before the leap, and happily assume the presence of plenty of things
that _aren't_ in Essential, or even "Priority: required" packages.
But that's just a hunch. I could be wrong.
Regards,
Branden
[1] ...but it happens more often than it could because a lot of
maintainer scripts need `dpkg --compare-versions`--functionality
that ideally would be put someplace that sees less vigorous
development, like the debianutils package. Debian's version
comparison algorithm is pretty stable and has served us well for 30
years, with only one change in that interval I'm aware of, that
being the logic to support `~` for "pre-release" semantics. This
algorithm has overcome significant external indifference and/or
hostility to Debian and been embraced elsewhere.[2]
In general, the package manager does not need to be, and should not
be, re-entrant.
[2] https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/filevercmp.c#n81
[3] ...by which I mean all stages of ยงยง6.6 and 6.7 of the Debian Policy
Manual.
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-configuration
signature.asc
Description: PGP signature
