Re: Changes in dpkg Pre-Depends
Hi!
On Tue, 2010-02-23 at 17:14:00 +1100, Robert Collins wrote:
> On Tue, 2010-02-23 at 05:20 +0100, Guillem Jover wrote:
> > I don't think this would be worth it, as Marco has also said, if the
> > system is hosed but you can still get to the point of obtaining a
> > package to install you might as well just obtain the broken files.
> > Of course you might have it already on apt's cache, but that's not
> > usually the case when you need it. :)
>
> dpkg is useful for more than just installing new packages;
Well, sure thing, :) although when I say install here I refer to the
act of running “dpkg -i” which might also imply upgrading a package,
and that's the only action you most probably would be doing when trying
to recover such system (see below).
> a hosed system might be fixed by removing a package, running
> maintainer scripts, both of which dpkg is the right tool for.
A hosed system in this context is one where dpkg is not operational.
otherwise there would be no problem to install/upgrade/remove/purge
whatever is needed to recover other kinds of system broknness. The
difference with such situation currently and with the proposed changes
is that it might possibly affect the newly dynamically linked libraries
too, and in that scenario there should be only need to either reinstall
the current version of the broken packages (as in files missing,
corrupt, etc) or upgrade to a new one.
As dpkg should only makes use of Essential packages or stuff it
Pre-Depends on, removing is not an action one should be performing to
recover. If any of the Essential packages dpkg directly relies on is
not functional, then a (partially or fully) statically linked dpkg (or
dpkg-deb) will not help anyway (as shared libraries are only
pseudo-essential).
Running maintainer scripts is just a “side effect” of installing (newly
or upgraded packages), removig or purging a package so the install case
is the only one that would apply here. And then the only scripts from
the new package on upgrade that need to be guaranteed to succeed are
preinst and prerm, as Essential packages should be functional even when
unconfigured. But if the system is so broken dpkg or its dependencies
cannot even run, then a maintainer script in shell or in C (dynamically
linked against libc) might not run either, and you'd need fully
statically linked maintainer scripts, but that solution only works if
you know beforehand something is broken and most probably would be
used only to recover from a packaging bug, for example.
So given all this, a (partially or fully) statically linked dpkg might
not be enough in all situations to recover a system were it itself is
not operational, and trying to cater to all such scenarios would imply
we'd need to fully statically link most of Essential. When just
transferring the broken files seems easier overall in a situation that
should only happen rarely (if at all).
> Not arguing for or against, just noting that you're being overly
> restrictive in your analysis of what a sdpkg might be used for.
That's possible, and I guess I might be lacking imagination, but in
what situation do you see you'd need to remove an Essential or a dpkg
Pre-Depends, to fix such broken system?
Also I don't disagree there are some merits to a statically linked
dpkg for specific situations or purposes, but not in the general case
and I don't think those are relevant to this proposal.
regards,
guillem
Reply to: