Re: If *-module depends on *-utils, should *-source recommend it?
Once upon a time Scott James Remnant said...
>
> 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.
Then wouldn't it make sense to avoid this state is possible? An unusable
package is obviously of no use. If it can be detected before
installation of a package that it will leave the old and new package
unusable, dpkg should not unpack the package.
> > > > 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
> > >
> > 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.
By looking at the set of packages to be installed, dpkg could determine
that the final installed state will be valid. During the transition from
the old valid package state to the new valid package state the system
will go through an inconsistent period, but it does that already. How is
this different?
I am suggesting that dpkg determine that a dependency is valid or not
without needing to unpack the data component of packages to be
installed.
> Actually users will be more likely using APT, which worries about this
> kind of thing all the time.
APT can not be told to install a .deb file. I appreciate the suggestion
posted earlier of setting up a local repository, but that is a rather
roundabout and cumbersome way to install a single .deb file.
As long as dpkg is still used to install .deb files, it would be better
if it managed the package installations in a more robust manner.
> > 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 also assume that dpkg will not install a package (sorry, "unpack but
not configure a package") if the package dependencies are not met. That
is the main point of dpkg, is it not - to manage package dependencies?
If I just wanted to install a package, I'd just unpack a tarball.
> I actually think dpkg's design is reasonably elegant
> in that it saves you having to repeat a step that failed last time.
This is just personal preference. I think the opposite about this. I
dont like it that dpkg maintains this state between each run and that
when I tell dpkg to install something, it may continue with something
from a previous failed installation. If I tell dpkg to "install A", I
expect it to install A and nothing else. Along the same lines, I dont
like it that dpkg maintains a "desired" state of a package. This should
be maintained by a higher level tool. dpkg should just install and
remove packages (and report on what is installed). It's state should
contain only what is installed.
But, as I say, this is just personal preference.
> If you didn't want the package to be unpacked before its dependencies
> are installed, you'd just check the dependencies before unpacking.
Exactly. So why doesn't dpkg check the dependencies before unpacking?
Oh, you mean I should manually check the dependencies before unpacking?
If I wanted to do that, I'd install a tarball. dpkg's purpose is to
manage dependencies so I dont have to.
However, to pick you up on your point about precision, it's not that I
want to prevent a package being unpacked before it's dependencies are
*installed*, but that I want to prevent it being unpacked before its
dependencies are *checked*.
Reply to: