On Tue, 2005-01-11 at 19:30 +0100, Eduard Bloch wrote: > * Scott James Remnant [Tue, Jan 11 2005, 08:19:21AM]: > > > > 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. > Precision. We're talking about a (relatively) complex process with many variables used in a wide variety of situations. Sure, we can wave our hands about and say "dpkg installs shit, make it do it differently" but then we wouldn't get anywhere. If one is proposing a change in dpkg's behaviour, it helps to be fluent in its existing behaviour, precise about the exact way one wishes to change it and knowledgeable about the repercussions of doing so. > 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 you mean "unusable", actually. That's not nitpicking either, that's pure pedantry. Actually, this vastly depends on the package, but yes, in general an unpacked-but-not-configured package is not yet usable. And nor should it be. > > > 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. > You didn't put much thought into that, did you? Make icecream depend on banana, while banana still depends on icecream. With your proposal, dpkg can't unpack either because neither dependency is satisfied. > 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). > Actually users will be more likely using APT, which worries about this kind of thing all the time. > Why cannot you just admit that dpkg sucks on this issue because there > are really no sanity checks before potential damage can be done? > There's a general assumption that if you install a package, you kinda want it installed. I actually think dpkg's design is reasonably elegant in that it saves you having to repeat a step that failed last time. > 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). > That's the installation equivalent of masturbation, fun but entirely pointless. If you didn't want the package to be unpacked before its dependencies are installed, you'd just check the dependencies before unpacking. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part