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

Re: Project Improvements



On Wed, May 25, 2022 at 10:33:22AM +0200, Paul van der Vlis wrote:
> I support many people with Debian, what I often see is that they remove a
> package, and then also the meta-package is removed. And later all
> dependencies of the meta-package are removed by accident.

Not to rain on your parade, but those people should consider upgrading
their Debian installations as since at least apt version 1.1 shipped
before current old-old-stable (that is, they run at best Debian 8 jessie
which is covered only by Extended LTS) apt actually marks dependencies
of packages in section metapackages as manually installed if the
metapackage is removed due to the removal of one of its dependencies
– but doesn't if you decide to remove the metapackage explicitly.

So, given:

Package: mydesktop
Depends: texteditor, browser
Section: metapackages

And mydesktop manual, the rest auto-installed:
$ apt autoremove => nothing to be done

$ apt autoremove mydesktop => removes also texteditor & browser

$ apt autoremove texteditor => removes also mydesktop,
                               but marks browser as manual

(This isn't specific to the autoremove command, it does happen for them
 all, even in full-upgrade. It is just easier to see this way.)


Something similar happens for packages which are put in Section: oldlibs
in that they move their manual marking (if they have it) to the
package(s) they depend on and mark themselves auto on upgrade to the
version moving to oldlibs.


As usual, both isn't really specific to apt but implemented in libapt,
so aptitude and co should behave similar as long as the conditions are
met.

Disclaimer: I implemented both a long time ago (somewhat improving on
similar existing behaviour… so even jessie is likely not effected, but
I am too lazy to check and it doesn't really matter that much anyhow)


That said, it is up to the maintainer to decide which section a package
belongs to and more importantly if a package is really that central to
the user experience of the metapackage that it must be a depends rather
than recommends.

(And yes, apt installs new recommends in upgrades since literal decades,
 so that is absolutely not a reason to use depends…)


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: