| 1 |
Mounir Lamouri wrote: |
| 2 |
> Zac Medico wrote: |
| 3 |
>> Sebastian Pipping wrote: |
| 4 |
>> |
| 5 |
>>> I propose support for license groups in ebuilds then, I guess. |
| 6 |
>>> |
| 7 |
>> That seems like a reasonable solution. So, an ebuild can do |
| 8 |
>> something like LICENSE="@GPL-2+" and that will expand to whatever |
| 9 |
>> the definition of the GPL-2+ license group happens to be. When a new |
| 10 |
>> version of GPL license comes out, we simple add it to that group, |
| 11 |
>> and none of the corresponding ebuilds have to be updated. |
| 12 |
>> |
| 13 |
> I suppose adding group license support in ebuilds will fix the problem |
| 14 |
> too. But I see a few disadvantages like: |
| 15 |
> - new behavior for @ operator: it will not only expand a group but also |
| 16 |
> adding a || operator (only for LICENSE) |
| 17 |
|
| 18 |
It's just a natural thing to do, given the use case, so I'm not sure |
| 19 |
that I'd consider it a "disadvantage". |
| 20 |
|
| 21 |
> - devs will have to maintain new groups |
| 22 |
|
| 23 |
It actually has potential ease maintenance because of the "code |
| 24 |
sharing" aspect. You only have to update the group definition in |
| 25 |
order to update all consumers of the group. |
| 26 |
|
| 27 |
> - group support in LICENSE has no other need that managing versioned |
| 28 |
> licenses |
| 29 |
|
| 30 |
Not necessarily. I can imagine other cases where the "code sharing" |
| 31 |
aspect might be useful. Also, imagine a case such as a version |
| 32 |
range. Doing that with operators could get messy, but it's quite |
| 33 |
simple using groups. Considering that licenses tend to have |
| 34 |
relatively few versions (compared to packages, for example), |
| 35 |
operators might introduce unnecessary complexity while not having |
| 36 |
the flexibility that groups have. |
| 37 |
-- |
| 38 |
Thanks, |
| 39 |
Zac |
Archives