1 |
On 06/01/17 04:27, Kent Fredric wrote: |
2 |
> On Tue, 3 Jan 2017 10:23:02 -0500 |
3 |
> Rich Freeman <rich0@g.o> wrote: |
4 |
> |
5 |
>> I tend to be firmly in the camp that a package shouldn't be removed |
6 |
>> unless there is evidence of a serious bug (and that includes things |
7 |
>> blocking other Gentoo packages). |
8 |
> I would probably go further and extend that argument to older versions |
9 |
> of packages, for similar reasons, at least in regards to older versions |
10 |
> with specific and exclusive APIs. |
11 |
> |
12 |
> Our duty as maintainers is to protect our users from the mistakes |
13 |
> upstream make as much as possible, not to protect ourselves as |
14 |
> maintainers from having difficult challenges. |
15 |
> |
16 |
> But our duty here doesn't extend to protecting users from problems the |
17 |
> user knows don't affect them. |
18 |
> |
19 |
> If for example, a media playback suite has a memory corruption bug when |
20 |
> playing media of a certain type, making it unusable when playing that |
21 |
> media, it does seem reasonable for us at first to kill that suite. |
22 |
> |
23 |
> However, if the user in question knows they're never going to play |
24 |
> that certain type of media, and only uses that media suite for a narrow |
25 |
> and specific kind of problem, then we're not serving them much utility, |
26 |
> or much freedom of choice by ripping this tool out of their hands for a |
27 |
> problem they'll never have. |
28 |
> |
29 |
> Maybe we need an intermediate option, where the sensible default when |
30 |
> we discover this kind of error is to remove it, but provide a way to |
31 |
> easily restore that package if the users are ok with it. |
32 |
> |
33 |
> Like, this is not my proposal, just an idea so you can see where I'm |
34 |
> headed with thoughts: |
35 |
> |
36 |
> If packages had a field called "BUGS=" it could contain an array of |
37 |
> bugs a package is known to contain, but can be conditionally avoided if |
38 |
> you're careful. |
39 |
> |
40 |
> Packages with non-empty BUGS= fields would be treated as hard-masked |
41 |
> for the purpose of repoman checks, and so packages that depend on |
42 |
> specific version ranges of packages with BUGS= fields are invalid, |
43 |
> and need their own BUGS= fields. |
44 |
> |
45 |
> Users get portage by default telling them "X package has to go away, |
46 |
> because it has bug #145 , #1286234, and #123756" |
47 |
> |
48 |
> And if this is not satisfactory, they can override portage with |
49 |
> |
50 |
> ACCEPT_BUGS="145 1286234 123756" |
51 |
> |
52 |
> You could even have |
53 |
> |
54 |
> BUGS=" x86? ( 112345 )" |
55 |
> |
56 |
> This to me sounds like a more user-empowering approach. |
57 |
> |
58 |
> The only questions to me are: |
59 |
> |
60 |
> - Do we have the resources to support this kind of strategy? |
61 |
> - How much additional complexity and confusion will this introduce for |
62 |
> users? |
63 |
> - Is that additional complexity and confusion something users want to |
64 |
> indulge, or is our current feature set already too complex. |
65 |
> |
66 |
> That last one is pretty much the one that weighs most on my mind |
67 |
> lately, with users frequently stumped by handling subslot upgrades |
68 |
> and required-use conflicts. |
69 |
> |
70 |
> Granted, this is just yet-another alternative flavour of hard-masking |
71 |
> things, so I'd rather we stick with careful use of hardmasks to inform |
72 |
> users of problems they might face, allowing them to contravene the hard |
73 |
> masks if they're feeling like they want to be adults. |
74 |
> |
75 |
> |
76 |
> |
77 |
+1 I like this proposal .. we are supposedly a distribution of Choice |
78 |
and Flexibility .. part of that is being an adult about making that |
79 |
choice available, and the consequences of it .. |
80 |
|
81 |
Just my 2c50 as usual ;) |