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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100223212050.ga18...@gaara.hadrons.org
