Re: If *-module depends on *-utils, should *-source recommend it?
Cameron Hutchison <email@example.com> writes:
> Once upon a time Steve Langasek said...
>> There is nothing in the -source package that actually requires (or should
>> recommend) the -utils package. A much better fix here is for people to get
>> over the fact that dpkg isn't apt.
> Apologies for continuing this but having read through the thread I still
> dont think I understand the issue with dpkg in this situation.
> Is the following scenario the issue here with dpkg? :
> foo-modules_1.0 is installed. It is standalone and does not require any
> other packages to be installed.
> foo-modules_2.0 is built from foo-source.
> foo-modules_2.0 depends on foo-utils.
> User runs "dpkg -i foo-modules_2.0_arch.deb"
> dpkg first removes foo-modules_1.0
> dpkg then check dependencies of foo-modules_2.0
> dpkg complains that foo-utils is not installed and aborts the
> installation of foo-modules_2.0
dpkg unpacks foo-modules_2.0 overwriting foo-modules_1.0 in
dpkg fails to configure foo-modules_2.0
> foo-modules is now in a broken state unable to be used.
> Networking depends on foo-modules so it is not possible to install
> foo-utils unless it is locally available.
Unless you reboot networking will still work since the old module will
still be loaded. Of cause thats of little help if you have a power
failure just then. :)
> Is this the scenario being argued over? If so, why does dpkg not first
> check the dependencies of foo-modules_2.0 before removing
> foo-modules_1.0? If not, could someone explain to me (or point me to a
> resource) what the issue is?
That is pretty much the issue. dpkg -i does an dpkg --unpack (which
succeeds) and then dpkg --configure (which fails). It could check
beforehand if the --configure can possibly succeed or not but IT
The most prominent opinion about this is LIVE WITH IT. dpkg is a
low-level tool and if you use it you are responsible to use it right.
If you can't or don't want to use a higher level tool like apt or