Mounir Lamouri wrote: > Zac Medico wrote: >> Sebastian Pipping wrote: >> >>> I propose support for license groups in ebuilds then, I guess. >>> >> That seems like a reasonable solution. So, an ebuild can do >> something like LICENSE="@GPL-2+" and that will expand to whatever >> the definition of the GPL-2+ license group happens to be. When a new >> version of GPL license comes out, we simple add it to that group, >> and none of the corresponding ebuilds have to be updated. >> > I suppose adding group license support in ebuilds will fix the problem > too. But I see a few disadvantages like: > - new behavior for @ operator: it will not only expand a group but also > adding a || operator (only for LICENSE)
It's just a natural thing to do, given the use case, so I'm not sure that I'd consider it a "disadvantage". > - devs will have to maintain new groups It actually has potential ease maintenance because of the "code sharing" aspect. You only have to update the group definition in order to update all consumers of the group. > - group support in LICENSE has no other need that managing versioned > licenses Not necessarily. I can imagine other cases where the "code sharing" aspect might be useful. Also, imagine a case such as a version range. Doing that with operators could get messy, but it's quite simple using groups. Considering that licenses tend to have relatively few versions (compared to packages, for example), operators might introduce unnecessary complexity while not having the flexibility that groups have. -- Thanks, Zac
