On 06/01/17 04:27, Kent Fredric wrote: > On Tue, 3 Jan 2017 10:23:02 -0500 > Rich Freeman <ri...@gentoo.org> 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. > > > +1 I like this proposal .. we are supposedly a distribution of Choice and Flexibility .. part of that is being an adult about making that choice available, and the consequences of it ..
Just my 2c50 as usual ;)
signature.asc
Description: OpenPGP digital signature
