Re: Dependencies et al
John Hasler writes:
Reco writes:
> The parent thread shows that at least some of the users are
> confused by metapackages.
I think that most users are totally ignorant of the nature or even the
existence of metapackages. As far as they are concerned the Lxqt
package *is* Lxqt and there is no way to get Lxqt other than to install
that package. I don't see any effective way to explain it to them,
either.
It's not clear to me why metapackages don't make more use of Recommends,
though. I understand that DE users expect a DE to provide an archiver,
but why does Lxqt *require* one? Isn't installation of Recommends still
turned on by default? Perhaps there's a need for "Weak-Depends" such
that Weak-Depends will always be installed but can be removed with no
more than a warning? This would be used whenever the maintainer cannot
imagine why anyone would want to install package A and not package B,
but A doesn't absolutely require B. All or almost all of the
dependencies in metapackages would then be weak.
I had wondered about the very same thing for multiple times already, but
this clear explanation above (thank you very much, John) has given me a good
opportunity to search the documentation for why meta-packages use Depends
instead of recommends. The best explanation I found so far is this:
https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-meta
Citing from that:
| 6.7.10. Best practices for meta-packages
| A meta-package is a mostly empty package that makes it easy to install a
| coherent set of packages that can evolve over time. It achieves this by
| depending on all the packages of the set. Thanks to the power of APT, the
| meta-package maintainer can adjust the dependencies and the user's system
| will automatically get the supplementary packages. The dropped packages
| that were automatically installed will be also be marked as removal
| candidates (and are even automatically removed by aptitude).
| gnome and linux-image-amd64 are two examples of meta-packages [...]
If I understand it correctly, meta-packages use Depends because this allows
packages like the kernel meta-package to function correctly: Changing a
Depends to a newer kernel version will cause older kernels to automatically
be uninstalled.
From my point of view, this clearly explains why the kernel meta-package
should make use of Depends fields, but for Desktop Environments, the
advantage of having a Depends is less clear to me:
On the one hand, it is an advantage that just removing the Desktop
Environment package will uninstall all related programs because this allows
trying them out and uninstalling them afterwards without leaving many
programs installed. On the other hand, the case of a user wanting to install
a desktop environment but "without this and that" is not possible with the
current design of meta-packages. Also, while I can generally think of cases
where names of packages that constitute a Desktop Environment change, from
a users point of view I would prefer not to propagate that change to
existing users, because they might be used to and happy with the previous
set of programs.
I can think of another good reason for having Depends: Ease of support.
Suppose there is someone asking for a complete Desktop Environment. As of
now, one just installs the meta-package. If it is already installed, one can
be pretty sure that all necessary programs are already on the system (they
might need to be activated by choosing a session in a display manager or
such). Thinking of a case where everything is just Recommends, it would be
possible that dependency problems (however they occurred in the first place)
cause a lot of the Desktop Environment to be missing but the meta-package
would still be installed leaving a "defective" (in terms of expected
programs to be available) installation without clear indication of the
why... I am, however, not sure if this problem is actually specific to
meta-packages but affects the whole system of Recommends?
YMMV
Linux-Fan
Reply to: