On Wed, 2006-11-22 at 01:10 +0100, Marien Zwart wrote: > On Tue, Nov 21, 2006 at 04:37:39PM -0500, Chris Gianelloni wrote: > > Well, we specifically didn't allow a "*" setting because of this. > > Ah, I missed that. Thanks. > > > Perhaps we should make it simple and specify that no interactive license > > should belong to a group? That would mean that since we don't include > > it in a group, it won't be part of the "wildcard" NON-INTERACTIVE (or > > whatever it's called) which would make the behavior the same as we > > currently have with check_license, since I think adding group support to > > check_license would be pointless when we're trying to replace it. > > I think that would be a good idea. Alternatively portage could export > ACCEPT_LICENSES with the groups expanded. I think that would be > slightly less confusing, although I agree it will probably not come up > in practice (since it is not that likely that licenses used with > check_license will be used in a group). But relying on that not > happening would be a bit icky.
Hrrrmn... expanding ACCEPT_LICENSE would make things less ambiguous. I still think that defining that no interactive licenses should be a part of a group would be a good idea. > Am I correct in assuming that check_license will be phased out > "eventually" (at some undefined time when everyone runs a portage > supporting ACCEPT_LICENSE)? Perhaps it would be a good idea to include > some information about how this new portage feature interacts with > ACCEPT_LICENSE in the glep (I am assuming more people than just me > were not aware check_license checked the ACCEPT_LICENSE env var)? That > is, explain licenses included in ACCEPT_LICENSE cause check_license to > be "silent", and explain if new ebuilds should be using it or not? Correct, check_license will be phased out, as portage will do the job of displaying the license and instructing the user on how to "accept" it. I do think some more information on how things currently work and how they will work could be useful, as it would remove some of the questions. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
