#include <hallo.h> * Scott James Remnant [Tue, Jan 11 2005, 08:19:21AM]:
> > dpkg unpacks the data contents (data.tar.gz) of foo-modules_2.0 into > > their final location in the filesystem (possibly overwriting the > > contents of the package being replaced) > > > > dpkg then checks dependencies of foo-modules_2.0 > > > > dpkg complains that foo-utils is not installed and aborts the > > installation of foo-modules_2.0 > > > dpkg does not abort the installation, the installation concludes with > the package in an unpacked state. If it had aborted the installation it > would have unwound various steps. Nitpicking. Why cannot you just admit that dpkg lets the package (*) in an unuseable state at this point? By unuseable, I mean unuseable (**) and not some special state flag written in dpkg's database that means nothing when the day ends. *: as "software", I mean files in the file system on their target location, not some theory definition of "package" within the packagement system **: for user that use it, read: the package contents on the filesystem > > I think the reversed order is correct and the current order is not - but > > that's based only on my limited understanding. Is there a reason that > > the data.tar.gz needs to be unpacked before the dependencies are checked > > to see if the package can be installed? > > > dpkg -i banana_2.0.all.deb icecream_1.0.all.deb > > (or 1,000-package equivalents given from APT or dselect which may > include quite convoluted conflict and replacement scenarios.) But to do this you need to know what to install and this can only be done by looking at the package metadata and getting the dependencies manualy. Of course this is the right way to do, but sometimes users are lazy (or just expect different things, and some of them appear here, with their arrogant attitude, pissed and beeing polemic). Why cannot you just admit that dpkg sucks on this issue because there are really no sanity checks before potential damage can be done? IMO it would be quite simple to work around that - do not overwrite existing files when you extract the tarball. Instead, write them to temporary locations, and move them to the right locations after all checks are done (or /dev/null when something failed). Simple strategy: - dpkg -i aumix_123.deb - dpkg puts files into /usr/bin/TMPNAME/new/aumix/, /usr/share/doc/TMPNAME/new/aumix/..., etc. - old files are copied (hardlinks) into .../TMPNAME/old/... - do dependency checks - remove old files (hardlinks) - move new files to target locations locations - run postinst - if okay, remove old files Yes, that strategy would allow a rollback, more or less. Regards, Eduard. -- Kippt der Bauer Milch in'n Tank, wird der Traktor tierisch krank.
signature.asc
Description: Digital signature
