On Wed, 2016-03-30 at 08:48:45 +0200, Helmut Grohne wrote:
I do have an answer to the absence of Maint-Depends now: Also add Runtime-Depends. Then Depends would simply beam both Maint-Depends and Runtime-Depends like Build-Depends means both Build-Depends-Arch and Build-Depends-Indep. I note that even without the rest of the changes,
the splitting of Depends would make deity (or at least Don) a little happier.
I'm not sure why it would make deity happier, it would still need to
satisfy both when installing stuff. Also the rpm equivalent has
instances for pre and post, and in that scenario Pre-Depends might
also deserve splitting I guess, which means a myriad of new fields. :/
If going the full rpm way, this also might imply in many cases duplicate information in multiple fields. Say you need package-x in postinst and
prerm, then we'd need to include it twice in Maint-Depends-Preinst and Maint-Depends-Prerm for example. This does not happen currently as you
list those packages once only in the weakest field necessary. Also I'm
not sure how rpm scriplets really work, but in our case our rollback mechanism in case of errors involves jumping from post to pre and the
other way around, so having such fine grained separation does not seem
worth it to me.
Even assuming a simple two-way split between Runtime and Maint
dependencies has other potential issue, such as triggers which are out-of-band (and not always declarative). If the package manager
frontends allowed to remove packages which are only maintscript
dependencies then this would be a mess. Another similar case is
disappearing packages which are also out-of-band events, another package might completely replace an existing one w/o the latter having any
previous knowledge of that fact, and that's file-based so not something
a frontend can predict. I can imagine that just removing maintscript-only dependencies might cause dependency issues.
There are at least two main use cases for this split of the dependencies
as you've mentioned: to make running the maintscripts from an external environment easier, and to be able to remove them in case of generating stripped down embedded images.
The first one I think is better served by trying to:
1) remove as many maintscripts as possible, via triggers for example,
or simply by making them unnecessary.
2) split the installation bootstrap logic into a different
maintscript, as described in the InstallBootstrap spec.
3) switch to a more declarative way of doing things.
Which I think would be a very welcomed initiative by the project at
The second depends on how much of a problem this really is. Do we know
if this would avoid 5 packages or 100, and how much those would weight
in terms of space or transitive dependencies? Because depending on the
size of the problem this becomes a non-argument IMO.
This one in addition
of being helped by some of the previous changes, could also be handled as simply informational annotations, such as a new field such as:
Depends: libcore, tool-a, tool-b
Which of course also has the problem of duplicated metadata, but is at
least really non-intrusive with the dependency solvers and much of our tooling.
So I hope you understand that my overall ecosystem complexity alarms
have all gone up. Which at the same time always feels bad because it
seems like a reaction against progress (even if that might end up
being misplaced :) !
dpkg-checkbuilddeps does not lock the external database. Why would dpkg have to?
I don't think this is the right question to counter that argument.
It's a valid question on its own though. The point is that these are
two separate universes. The installed system must preserve integrity
at all costs, when that is lost your running system is broken and it
might stop running at all, stop booting, etc. If the dependencies
disappear while you are building, at most you get a broken build. You
could always retry it and that does not affect the integrity of the
system as long as you don't try to install broken packages for
Is it dangerous to change the package state while building? Certainly!
And we might want to perhaps run dpkg-checkbuilddeps after the build
is finished and abort if the deps are not satisfied. This still leaves
a big window inbetween where packages might have been removed and
added back though.
What is the point in making different assumptions on dpkg and on dpkg-checkbuilddeps? Both construct something external to the current installation.
Because in the dpkg chroot-less case we are still operating on the
chroot contents so integrity is paramount. But see above.
Also from the point of creating small Debian installations, splitting Depends into pieces would be preferable. rpm already does that:
This would allow us to strip an essential installation of packages only required for configuring packages.
You see, I have a strong preference for allowing arbitrary packages to
be required from the outer installation.
This is still very Debian specific, as in it requires the external environment to be a Debian system too. Even worse, ISTM it is even
suite specific! Say you depend on a package conf-a >= 2.0 un suite 1.0
from the maintscripts, but the external distribution with suite 2.0
contains conf-a 2:1.0 (even though this would probably even cause
problems on upgrades). Another actual case would be if the depends
would be on something like git, which has been different things in
Debian depening on the suite. And of course different derivatives, or distributions based on dpkg but not necessarily transitively on Debian
do not share the Debian package-version namespace.
|Location:||Huddersfield, West Yorkshire, UK|
|Nodes:||8 (1 / 7)|