[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dependencies et al



	Hi.

On Mon, Oct 07, 2019 at 06:34:20PM +0200, Linux-Fan wrote:
> 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.

It could work this way, but currently it does not in this specific case.
See /etc/apt/apt.conf.d/01autoremove* .
Current behaviour is "we do not autoremove the current kernel and the
one that's installed before". Sane enough, if you ask me.


> 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.

It's an improvement over the current behaviour IMO.

User tries to uninstall a program, for instance - "xarchiver", and user
has "lxqt" metapackage installed. User sees that apt tries to install
another dependency of "lxqt" along with removing the xarchiver.
Or, user has "lxde" metapackage installed. User tries to remove
"xarchiver", which removes "lxde" by dependency, which removes all of
LXDE as a result.

In the former case user has to guess the metapackage which forces such
replacement. In the latter case user is scared of the dependencies
(because they remove half of the "system").


> 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.

Why, it's possible. But user cannot use metapackages in such case, and
picking the needed packages one by one is tedious at best.
Which beats the primary purpose of metapackages.


> I can think of another good reason for having Depends: Ease of support.
...
> Thinking of a case where everything is just Recommends, it would be
> possible that dependency problems (however they occurred in the first place)

A catch here is that Recommends are treated as Depends in a default
Debian installation. A user can disable Recommends installation, but
it's discouraged. See last month discussion on this at this list, for instance.

So, for the default apt settings, there is no visible difference between
Depends metapackage and Recommends metapackage.

The real fun starts then the user discovers that APT::Install-Recommends
setting.

Reco


Reply to: