On Sun, Jun 07, 2026 at 08:39:08PM +0200, Drew Parsons wrote:
The tracker page for fenics-dolfinx at 
https://tracker.debian.org/pkg/fenics-dolfinx
currently includes an autoremoval box in "action needed" reporting that 
fenics-dolfinx
is Marked for autoremoval due to getfem.

But the provided reason is not sufficient for taking any action (beyond fixing 
getfem itself,
which is not always practical).

In practice if fixing getfem itself is not a solution for you, you should do nothing as it's unlikely you will be willing to remove deps from your package to break the chain.

fenics-dolfinx does not depend on getfem,
and no package that fenics-dolfinx depends on depends on getfem.

Assuming this is true and by "depend" you also mean "build-depend", you just need to go deeper.

The message box adds the weasel word 'transitively':  "depends (transitively) on 
getfem".
But what does that mean?

I'm surprised this question is asked from time to time, because it looks obvious to me, but maybe it's enough to not understand that when a package is autoremoved, everything that (build-)depends on it is removed recursively.

Again, no package that fenics-dolfinx depends on depends on getfem.

What about packages that depend on packages that fenics-dolfinx depends on?

How I am supposed to interpret this adverb 'transitively'.

https://www.merriam-webster.com/dictionary/transitive meaning 2.

This instruction to autoremove "(transitively)" must come from somewhere.
It's not pixie dust sprinkled over the packages just to annoy package 
developers.

I'm also surprised, but not that much, that some maintainers are so frustrated by this feature.

How does tracker know that this package is marked for autoremoval?
Where does the knowledge about this autoremoval come from?

I assume it's https://udd.debian.org/cgi-bin/autoremovals.cgi or an equivalent source.

If the reason (the transitive dependency) can't fit in the tracker info box 
itself,
then please at least provide a link to a page where this 
remove-due-to-transitive-dependency
is documented, so we can review why an unrelated package is triggering 
autoremoval.

To my knowledge there is no page where the chain(s) between the RC-buggy package and it's (transitive) revdep are traced, you need to do it manually.
--
WBR, wRAR

Attachment: signature.asc
Description: PGP signature

Reply via email to