On Tue, 3 Jan 2017 10:23:02 -0500 Rich Freeman <[email protected]> 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.
pgpysN544Xf3x.pgp
Description: OpenPGP digital signature
