Re: If *-module depends on *-utils, should *-source recommend it?
Scott James Remnant <scott@netsplit.com> writes:
> 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.
Sure it can, dpkg --unpack just keeps on working. It can't install
them and it already shouldn't. Sorry but you started being pedantic.
The only reason why it actualy can install them is that dpkg ignores
some somewhat random Depends in cycles to break them. The same cycle
breaking can apply when testing before the unpack as dpkg uses after
the unpacking.
>> 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.
apt also just breaks cycles at some point and it actually does screw
up and fails quite often when doing larger updates. See the BTS for
such cases in apt.
>> 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.
Doing the 'can this be configured after unpacking' check before
unpacking would mean you haven't yet unpacked anything. You would not
repeat any step. You only get the resulting error before dpkg does the
first step of a 2 step process instead of after the first step.
Whether that is a good thing or not can be argued but if you wan't
dpkg to only do step 1, maybe because you don't want to type such a
long command line with all debs on it, then you can always use
--unpack first and --configure -a later.
>> 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.
I agree that this isn't a good idea but for completly different
reasons. Unpacking packages to a temp location first would greately
increase the disk usage during updates and many system (all of mine)
probably don't have that much spare space lying around.
Imagine a woody->sarge update where all debs are first unpacked to
temp files, all 3GB of your installed debs.
> If you didn't want the package to be unpacked before its dependencies
> are installed, you'd just check the dependencies before unpacking.
How do you suggest that is checked? Don't say manual.
> Scott
MfG
Goswin
Reply to: