Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Kent Fredric]

On Tue, 3 Jan 2017 10:23:02 -0500
Rich Freeman <rich0@g.o> wrote:

> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).

I would probably go further and extend that argument to older versions
of packages, for similar reasons, at least in regards to older versions
with specific and exclusive APIs. 

Our duty as maintainers is to protect our users from the mistakes
upstream make as much as possible, not to protect ourselves as
maintainers from having difficult challenges.

But our duty here doesn't extend to protecting users from problems the
user knows don't affect them.

If for example, a media playback suite has a memory corruption bug when
playing media of a certain type, making it unusable when playing that
media, it does seem reasonable for us at first to kill that suite.

However, if the user in question knows they're never going to play
that certain type of media, and only uses that media suite for a narrow
and specific kind of problem, then we're not serving them much utility,
or much freedom of choice by ripping this tool out of their hands for a
problem they'll never have.

Maybe we need an intermediate option, where the sensible default when
we discover this kind of error is to remove it, but provide a way to
easily restore that package if the users are ok with it.

Like, this is not my proposal, just an idea so you can see where I'm
headed with thoughts:

If packages had a field called "BUGS=" it could contain an array of
bugs a package is known to contain, but can be conditionally avoided if
you're careful.

Packages with non-empty BUGS= fields would be treated as hard-masked
for the purpose of repoman checks, and so packages that depend on
specific version ranges of packages with BUGS= fields are invalid,
and need their own BUGS= fields.

Users get portage by default telling them "X package has to go away,
because it has bug #145 , #1286234, and #123756"

And if this is not satisfactory, they can override portage with 

ACCEPT_BUGS="145 1286234 123756"

You could even have

BUGS=" x86? ( 112345 )" 

This to me sounds like a more user-empowering approach.

The only questions to me are:

- Do we have the resources to support this kind of strategy?
- How much additional complexity and confusion will this introduce for
  users?
- Is that additional complexity and confusion something users want to
  indulge, or is our current feature set already too complex.

That last one is pretty much the one that weighs most on my mind
lately, with users frequently stumped by handling subslot upgrades
and required-use conflicts.

Granted, this is just yet-another alternative flavour of hard-masking
things, so I'd rather we stick with careful use of hardmasks to inform
users of problems they might face, allowing them to contravene the hard
masks if they're feeling like they want to be adults.