| 1 |
On 08/05/2016 01:11 PM, Chí-Thanh Christopher Nguyễn wrote: |
| 2 |
> |
| 3 |
> I disagree. ACCEPT_LICENSE does not change the files which the ebuild |
| 4 |
> installs on the user's filesystem, nor does it interfere with subslot |
| 5 |
> dependency calculations like EAPI changes do. Therefore a new revision |
| 6 |
> is not needed. |
| 7 |
|
| 8 |
Those two are sufficient for a new revision, but not necessary. Use |
| 9 |
common sense. If not doing a revision is going to negatively affect |
| 10 |
people, then you should do a revision. |
| 11 |
|
| 12 |
|
| 13 |
>> If you installed something whose EULA says it can hijack your webcam and |
| 14 |
>> post naked pictures of you to slashdot, but it incorrectly had |
| 15 |
>> LICENSE="GPL-2", wouldn't you want to find out that I corrected it? |
| 16 |
> |
| 17 |
> That is the package manager's task. I do get reminded if a package which |
| 18 |
> I have installed is now masked by package.mask, maybe something like |
| 19 |
> this would work for licenses too. |
| 20 |
> |
| 21 |
|
| 22 |
The package manager's task is well-defined, and that isn't part of it. |
| 23 |
Saying "maybe it's possible somehow some day" is not a good reason to |
| 24 |
screw up ACCEPT_LICENSE handling with certainty right now. |
| 25 |
|
| 26 |
To bring this back on topic. If I change LICENSE, I'm going to do it in |
| 27 |
a new revision, because I want it to work right -- to each his own. At |
| 28 |
the moment, doing a revision on top of a stable ebuild is not optimal, |
| 29 |
because little bug fixes like that can remain in unstable for a year. A |
| 30 |
carefully-worded exception could alleviate that, when the change could |
| 31 |
in no way affect architecture stability. |
Archives