Guillem Jover wrote: > On Fri, 2009-11-27 at 21:09:57 +0200, Eugene V. Lyubimkin wrote: >> Guillem Jover wrote: >>> Something like this could do (on a clean lenny chroot): >>> >>> r...@gaara:~# export LC_ALL=C >>> r...@gaara:~# dpkg --auto-deconfigure --unpack libc-bin_2.10.2-2_amd64.deb >> This: >> >> a) may break the planned changeset by allowing dpkg to do unwanted actions; > > This is already the case, dpkg might disappear a package in some > situations, and the front-ends should be able to cope with those > cases, that's why those events are reported via the status-fd pipe. Personally I consider this as bad design, so I'm trying to minimize the impact whenever possible.
>> b) is package(libc)-specific and not generic solution, because the action >> sequence proposed in the first message of the thread will probably work >> flawlessly for almost all other packages, it's only dpkg is "smart" enough to >> break the upgrade with no actual reason, and the front-end has no way to >> predict it. > > Always using --auto-deconfigure should be safe, and is the generic > solution. Your “flawless” solution involves several force options, No, this is not true. The only force option required today for this action is "turning off" PATH check by --force-path. The '--auto-deconfigure' is a hack IMO, the right way is to provide, finally, a way to request several different actions at once from dpkg. > making files unavaiable from the file system for a time window, that > could be not short if there was an error during the transaction that > made dpkg exit, it's certainly not the correct solution. I guess if there will be some unpredictable error during transaction, dpkg database of 'what files belong to what package' may be messed by this in-place replacing. Am I wrong? > And this case can be spotted easily when a package replaces another > one and that other breaks this first, the replacing one should always > be installed first, otherwise the system will end up with missing files > for a period of time. There may be much worse intermediate situations during upgrade. > Also your continuous use of force options in cupt leaves to be desired > (just saw the new --force-bad-path), pointing as excuse a breakage in > dpkg when it seemed pretty clear the ordering chosen was wrong From the point of view of the high-level package manager - no. > and > can leave the system in a broken state. Not to mention as I've said > several times already that apt manages to handle all those situations > with *no* force option at all. I've said already that I don't care what can apt do. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
