Re: Package marked for autoremoval due to closed bug?
Hi Paul,
Am Fri, Mar 15, 2024 at 09:52:06PM +0100 schrieb Paul Gevers:
> For bookkeeping purposes, please usertag downgraded bugs with user
> release.debian.org@packages.debian.org and usertag time_t-downgrade.
>
> Please be careful with downgrading RC bugs.
I agree with Ian that it might make sense that Steve, who probably has a
complete list of the bugs, can do this more safely than individual
maintainers. (BTW, thanks again to Steve for doing all the work.)
I think this migration has shown another problem which was not yet
dicussed here. In Debian Med and R pkg team we identified packages
where a time_t transition would be
a) complex (there was no patch provided by time_t people)
b) not helpful for users since usage on 32bit is probably zero
Thus we considered it a good idea to remove 32bit architectures of those
packages and its dependencies. This has shown that removing packages is
a similarly time consuming way of dealing with this. The method to file
individual bug reports for every single package on the side of the
maintainer as well as dealing with the actual removal done by ftpmaster
is quite inefficient. The removal bug for emboss[1] was filed six weeks
ago (1 Feb 2024) and countless testing removal warnings were sent to
the maintainer list since it is not fixed until now. Even worse for
r-bioc-rhtslib[2] which had quite a tree of rdepends and kept several
people (including ftpmaster) busy.
Please understand me correctly: It is not blaming ftpmaster to be slow
with ROM requests. Maybe I could have adjusted severity somehow - I
just don't know any documentation what is appropriate or not. I made
mistakes myself when filing ROM bugs against rdepends.
My point is: I as a maintainer have control about what is inside the
pool. But once a package is there I have a hard time to get it removed
again. This does not make sense. We have tools who can generate a
dependency tree. So filing separate bugs on one hand and deal with
separate bugs on the other hand is somehow a rudiment from last century.
I wished we could solve this more elegantly.
Kind regards
Andreas.
[1] https://bugs.debian.org/1062371
[2] https://bugs.debian.org/1063376
--
http://fam-tille.de
Reply to: