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

[Michael Mol]

On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote:
> 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.

I really like where this is going.

>
> The only questions to me are:
>
> - Do we have the resources to support this kind of strategy?

How much of the work can be automated? I.e. can bugs on bgo be tagged such 
that a maintainer's script can scoop up the bugs and apply them, at least 
naively? Being able to express something like "x86? (!mmx)" clearly in a bgo 
ticket's metadata could well be useful, and would lend itself to something 
like this.

The bigger resource drain, I suspect, will come from maintaining new ebuilds 
of old packages; as eclass development and maintenance seeks to eliminate old 
and buggy code, old ebuilds will need to be dragged along for the ride.

> - How much additional complexity and confusion will this introduce for
>   users?

I think you'd want autounmask to not support applying changes for 
automatically unmasking bugs. Apart from that, it shouldn't result in any 
additional complexity or confusion for users who aren't deliberately holding 
on to package versions that have known bugs. Most of the users I've seen who 
would be faced with this functionality are the users who will run a gymnastics 
course just to use a browser version that has an old, familiar interface.

> - Is that additional complexity and confusion something users want to
>   indulge, or is our current feature set already too complex.

So long as it stays out of a user's way until the user needs it, I wouldn't 
say it adds needless complexity from a user's perspective.

>
> 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.

Choosing to engage with this functionality sounds like very much an opt-in 
experience for the user; the path of least resistance is to go ahead and 
update (and that will generally provide the best-tested global configuration), 
but if they wish to hold on to difficult configurations, they can at least do 
that.

There is one other advantage to a system like this; it permits for a larger, 
deeper tree, with old versions more frequently available. That'll significantly 
assist the upgrade efforts of people who go ridiculous amounts of time between 
@world updates, people who are dusting off stowed systems, etc.

>
> 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.