| 1 |
Marien Zwart <marienz@g.o> posted |
| 2 |
20061121183634.GA6948@×××××××.localdomain, excerpted below, on Tue, 21 |
| 3 |
Nov 2006 19:36:35 +0100: |
| 4 |
|
| 5 |
> Since check_license was (I assume) originally added because it was |
| 6 |
> required for certain (mostly games) ebuilds: is the possibility to accept |
| 7 |
> the license by putting a wildcard or group in ACCEPT_LICENSE "compatible" |
| 8 |
> with those licenses? If it is not this would need some more thought: it |
| 9 |
> would be quite confusing if certain licenses did not follow the same |
| 10 |
> "rules" for groups and wildcards as other licenses, or if portage followed |
| 11 |
> different rules at resolve time than check_license in eutils does. |
| 12 |
|
| 13 |
As I've read the GLEP (as proposed for update), you are missing something |
| 14 |
here. The package manager's treatment of ACCEPT_LICENSE will simply be |
| 15 |
masking/unmasking of the appropriate ebuilds. It won't change whether |
| 16 |
interactive license agreement is required or not, simply whether such a |
| 17 |
package is masked or not. Thus, accepting an interactive license will be |
| 18 |
a two-stage process -- (1) unmask it by setting ACCEPT_LICENCE |
| 19 |
appropriately so the ebuild can even be considered for merging, (2) emerge |
| 20 |
the package and hit the interactive merge section, actually accepting the |
| 21 |
license there. |
| 22 |
|
| 23 |
Setting ACCEPT_LICENSE therefore won't actually accept it. It'll simply |
| 24 |
tell the package manager whether it can consider certain packages or not. |
| 25 |
Once the package manager can do so, it can go ahead and actually display |
| 26 |
the license for agreement if the package is actually merged. |
| 27 |
|
| 28 |
-- |
| 29 |
Duncan - List replies preferred. No HTML msgs. |
| 30 |
"Every nonfree program has a lord, a master -- |
| 31 |
and if you use the program, he is your master." Richard Stallman |
| 32 |
|
| 33 |
-- |
| 34 |
gentoo-dev@g.o mailing list |
Archives