Re: Removing packages perhaps too aggressively?
On Sat, Feb 03, 2018 at 01:25:14AM +0100, Adam Borowski wrote:
> On Sat, Feb 03, 2018 at 12:39:57AM +0100, Wouter Verhelst wrote:
> > On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote:
> > > If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right?
> >
> > This doesn't compute.
> >
> > A package can be orphaned and still perfectly functional; a package can
> > be orphaned and RC-buggy. A package cannot, however, be RC-buggy and in
> > a "still works" state. If it's genuinely RC buggy, then by definition it
> > no longer works properly or it's causing problems.
>
> Copyright problems don't make the package any less useful.
That would be the "causing problems" part. Legally we may not be able to
redistribute it if there are copyright problems.
> > If it's RC buggy because the environment changed and it's now holding
> > back a transition or some such, then it's actively causing problems and
> > should be fixed or removed.
>
> > If it's RC buggy because it broke and now crashes on startup, then it,
> > well, broke and should be fixed or removed.
>
> What if it crashes on startup only with systemd? This currently means the
> majority of users, but doesn't make the package any less useful for me.
That sounds like an "important" bug to me, then. If the bug indeed does
not occur with other init systems, that means the package is not totally
useless.
> > If it's RC buggy because someone had a bad case of "my use case is the
> > most important one in the world and this package should be fixed NOW",
> > then, well, fix the severity (it can be "important" without being RC
> > buggy) and it can remain.
>
> What if it FTBFSes on s390x? What if it may cause serious data loss on ext2
> with a split /var setup?
If the package is not likely to be useful on s390x, then ask for the
removal of just the s390x binaries, and downgrade the bug severity. The
other example seems somewhat contrived and unlikely; I doubt such things
are actually a problem in practice.
> > But if a package is RC buggy, then it is *broken*, and should either be
> > removed or fixed. You don't need to take over maintenance of a package,
> > but if you think it's important enough to be retained in the archive,
> > ensuring that it at least doesn't have any RC bugs anymore shouldn't be
> > too much to ask. If you can't do that, then it's perfectly normal for it
> > to be removed.
[limited time]
I understand all that, and it does make sense. But Debian as a whole has
a limited amount of time for everything, and it makes sense to not get
distracted by things that nobody's interested in.
If you care about an orphaned package, and there's an RC bug, it doesn't
hurt you to say "I want to fix this bug so the package can migrate
again, but I don't have the time right now". That should be enough to
ensure people don't file removal bugs on it.
Finally, a removal isn't a way of saying "this package has no purpose
being in Debian". It's just a way of saying "we're sorry we couldn't fix
this package, but it seems unlikely". If you care enough, you can always
take the last version of the package, fix it, and reupload it. There's
no real reason why it wouldn't get through NEW.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: