From: Zac Medico <zmedico@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Date: Sat, 05 Sep 2009 14:37:16 -0700 [thread overview]
Message-ID: <4AA2DA0C.7070403@gentoo.org> (raw)
In-Reply-To: <4AA29E31.6090604@gentoo.org>
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
next prev parent reply other threads:[~2009-09-05 21:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 22:12 [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?) Mounir Lamouri
2009-08-31 22:30 ` Rémi Cardona
2009-09-03 20:50 ` Mounir Lamouri
2009-09-01 2:21 ` Sebastian Pipping
2009-09-01 5:54 ` [gentoo-dev] " Duncan
2009-09-03 21:10 ` Mounir Lamouri
2009-09-03 21:15 ` Rémi Cardona
2009-09-03 21:27 ` Mounir Lamouri
2009-09-04 4:53 ` Duncan
2009-09-04 15:01 ` Rémi Cardona
2009-09-04 18:52 ` David Leverton
2009-09-04 20:04 ` Rémi Cardona
2009-09-04 20:08 ` Ciaran McCreesh
2009-09-05 14:03 ` Maciej Mrozowski
2009-09-05 15:02 ` Ciaran McCreesh
2009-09-06 0:34 ` Thomas Anderson
2009-09-06 6:31 ` Rémi Cardona
2009-09-03 21:08 ` [gentoo-dev] " Mounir Lamouri
2009-09-04 21:11 ` Sebastian Pipping
2009-09-05 1:06 ` Zac Medico
2009-09-05 8:40 ` [gentoo-dev] " Duncan
2009-09-05 9:28 ` [gentoo-dev] " Ulrich Mueller
2009-09-05 10:59 ` Zac Medico
2009-09-05 17:21 ` Mounir Lamouri
2009-09-05 18:41 ` Ulrich Mueller
2009-09-06 0:14 ` Sebastian Pipping
2009-09-05 21:37 ` Zac Medico [this message]
2009-10-01 2:01 ` Sebastian Pipping
2009-10-01 13:09 ` volkmar
2009-09-04 15:47 ` Jeremy Olexa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AA2DA0C.7070403@gentoo.org \
--to=zmedico@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox