| 1 |
Michael Orlitzky posted on Sat, 12 Aug 2017 10:14:18 -0400 as excerpted: |
| 2 |
|
| 3 |
> On 08/12/2017 06:29 AM, Rich Freeman wrote: |
| 4 |
>> |
| 5 |
>> My gut feeling is that the change you want is probably a good thing, |
| 6 |
>> but it will never happen if you can't provide a single example of |
| 7 |
>> something bad happening due to the lack of a revbump. |
| 8 |
> |
| 9 |
> There's an unfixed security vulnerability with USE=foo, so we drop the |
| 10 |
> flag temporarily. Users who had USE=foo enabled will keep the vulnerable |
| 11 |
> code installed until they update with --changed-use or --newuse. |
| 12 |
> |
| 13 |
> Even with the devmanual improvements, the advice we give is conflicting: |
| 14 |
> |
| 15 |
> * If you fix an important runtime issue, do a revbump. |
| 16 |
> |
| 17 |
> * If you drop a USE flag, don't do a revbump. |
| 18 |
> |
| 19 |
> What if you fix a runtime issue by dropping a flag? It's more confusing |
| 20 |
> than it has to be: the USE flag exception interacts weirdly with all the |
| 21 |
> other rules. |
| 22 |
|
| 23 |
Bad example as it's a security vuln, which requires masking/removing |
| 24 |
vulnerable versions, which will require a version bump in ordered to |
| 25 |
prevent downgrades if it was the latest visible for a (stable or ~arch) |
| 26 |
keyword. |
| 27 |
|
| 28 |
So the version bump is effectively mandatory due to security overrides in |
| 29 |
any case, and that it was fixed by a temporary USE flag drop doesn't |
| 30 |
change things at all. If that security-override isn't explicit in |
| 31 |
current documentation, that'd be the bug, not the fact that use-flag |
| 32 |
drops don't on their own require a version-bump. |
| 33 |
|
| 34 |
-- |
| 35 |
Duncan - List replies preferred. No HTML msgs. |
| 36 |
"Every nonfree program has a lord, a master -- |
| 37 |
and if you use the program, he is your master." Richard Stallman |
Archives