[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: If *-module depends on *-utils, should *-source recommend it?

#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
**: 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.

Kippt der Bauer Milch in'n Tank, wird der Traktor tierisch krank.

Attachment: signature.asc
Description: Digital signature

Reply to: