| 1 |
On Tue, 26 Aug 2008 20:17:48 -0600 |
| 2 |
Ryan Hill <dirtyepic@g.o> wrote: |
| 3 |
|
| 4 |
> Should LICENSE changes require a revision bump? |
| 5 |
|
| 6 |
A licence changes what get's installed, ok the files are the same, but |
| 7 |
the meaning of having the same files is different. So I say yes. |
| 8 |
|
| 9 |
> It kinda seems to me the answer should be yes. I don't know if any PM |
| 10 |
> currently implements LICENSE filtering so there may not be any |
| 11 |
> technical reason for it yet. And so I guess it comes down to a |
| 12 |
> philosophical question - what determines the licence(s) a currently |
| 13 |
> installed package is covered by? My thought is that this would be the |
| 14 |
> value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install |
| 15 |
> time, and therefore a change in the tree requires reinstallation to |
| 16 |
> change that value. |
| 17 |
|
| 18 |
Correct. |
| 19 |
|
| 20 |
> On the other hand, it also seems completely ridiculous from a |
| 21 |
> practical POV to have to wait 30 days (and waste arch team resources) |
| 22 |
> to fix an incorrect licence on a stable package. |
| 23 |
|
| 24 |
I think it should be sensible to make the stabilization request a lot |
| 25 |
earlier specifying the reason behind the creation of that newer |
| 26 |
revision in the bug and the stabilization process should be pretty much |
| 27 |
automatic, without wasting to much time from arch teams. |
| 28 |
|
| 29 |
On the other hand, I think it would be wise to create an explicit |
| 30 |
exception for this case in stabilization rules and to allow the uploader |
| 31 |
of the corrected ebuild to keep the same KEYWORDS instead of |
| 32 |
downgrading them to unstable. |
| 33 |
|
| 34 |
Kindest regards, |
| 35 |
Yuri. |
Archives