1 |
On Thu, Sep 22, 2005 at 01:30:00PM -0400, Chris Gianelloni wrote: |
2 |
> On Thu, 2005-09-22 at 11:46 -0500, Brian Harring wrote: |
3 |
> > Actually, it does have to deal with glep23, and you already stated in |
4 |
> > one of you emails (an "interim solution *now* since I've not heard |
5 |
> > anything from GLEP23 for some time"). |
6 |
> |
7 |
> This is an interim solution only in that it flags a package as |
8 |
> commercial until there is some kind of group created to fill that role. |
9 |
> Personally, I don't think a group *should* be created for commercial |
10 |
> licenses, as they are *not* equal in any way and should be judged |
11 |
> individually, rather than as a group. In that case, this would be a |
12 |
> permanent solution. |
13 |
|
14 |
Yet what you're proposing *is* a marker on packages as "this is |
15 |
commercial", in effect a license grouping that's not properly |
16 |
implemented. |
17 |
|
18 |
> > Further, where do you think you're going to migrate the check for this |
19 |
> > license to? |
20 |
> |
21 |
> We wouldn't check for *this* license. We would be checking for the |
22 |
> *real* license. |
23 |
> |
24 |
> So rather than using "check_license" in pkg_setup, we would be using |
25 |
> "check_license Q3AEULA". As for where it will eventually migrate (ala |
26 |
> GLEP23), I don't know, and honestly, it isn't my concern. |
27 |
|
28 |
It's actually your concern whether you realize it or not. |
29 |
|
30 |
Your idea of just ignoring "commercial" if it appears in |
31 |
license.split() means that ACCEPT_LICENSE implementation now gets |
32 |
screwed with, and has to start maintaining a whitelist of |
33 |
strings to exempt from checks. |
34 |
|
35 |
Why is this an issue? LICENSE field isn't a "one of the licenses |
36 |
listed", it's "all of the licenses listed following depset syntax |
37 |
rules". Same syntax as DEPEND. In other words, you can't stick a |
38 |
daft marker into the LICENSE field just the same as you can't stick |
39 |
daft atom's into DEPENDS; portage *must* resolve it. If the LICENSE |
40 |
depset doesn't match the users ACCEPT_LICENSE, then the package is |
41 |
masked. What you're proposing directly breaks glep23 (re-read the |
42 |
EBUILD License Variable section). |
43 |
|
44 |
(Heading it off), no, a || ( DOOM3 commercial ) won't work either, |
45 |
that's _either_ commercial license accepted, or doom3. |
46 |
|
47 |
|
48 |
> > FYI, accept_license checks have been sitting in svn/cvs for about a |
49 |
> > month, same as use deps. No, you can't use them now in a released |
50 |
> > portage, but that's not much of a reason to introduce a fake license |
51 |
> > I'm sitting. Further, a better approach instead of people adhocing |
52 |
> > yet another band aid in the tree would be to chip in- you want glep23? |
53 |
> |
54 |
> Yes, I want GLEP23, but as I have said, I think this *could* be a |
55 |
> permanent solution, if used properly. |
56 |
|
57 |
Nope, see above. |
58 |
|
59 |
It's the same old issue of "we want portage to do xyz", then something |
60 |
ugly/bad gets implemented that is a kludge getting in the way of a proper |
61 |
solution. |
62 |
|
63 |
That's harsh, but it's also the truth from being on the receiving end |
64 |
of portage bugs/watching the tree. It's easier to slap a (imo) crap |
65 |
solution into the tree then to do the proper route of trying to |
66 |
implement a proper solution. |
67 |
|
68 |
|
69 |
> > help bring the *proper*, agreed upon solution to a stable portage, not |
70 |
> > taking the easier route. |
71 |
> |
72 |
> OK. I'm going to ask a question of you. If you do an "emerge -S doom3" |
73 |
> on your system, how would you know that the DOOM3 license is a |
74 |
> commercial license? How would you know the difference between "doom3" |
75 |
> and "doom3-demo", which happen to have the *exact* same license? How |
76 |
> would you know that "doom3" requires a purchase? How would GLEP23 |
77 |
> resolve this? |
78 |
> |
79 |
> Now, if you can give me a solution other than the one that I have |
80 |
> provided, then I'll gladly accept it. As it stands, I only see one way |
81 |
> to provide this information to our users, and that is to add it |
82 |
> *somehow* into the ebuilds. This means either via LICENSE or some new |
83 |
> variable. The advantage to using LICENSE is that it works *now* on all |
84 |
> versions of portage. It also works *now* on packages.gentoo.org's |
85 |
> pages. |
86 |
|
87 |
Logic here is rather flawed. |
88 |
|
89 |
How do you know that the GPL is a 'opensource' license? How do you |
90 |
know that the sorcerer public license is anti-forking? |
91 |
You get off your ass and look in the licenses directory, that's how. |
92 |
|
93 |
What you're proposing doesn't in any way help with educating people on |
94 |
what the licenses are that they're accepting; sticking "commercial" |
95 |
into the license field is a bad hack, pure and simple. |
96 |
|
97 |
I'll kill this one off further down... |
98 |
|
99 |
|
100 |
> > The original proposed angle (glep23 implementation isn't here) is |
101 |
> > jumping the gun, and the angle of "it indicates it costs money" isn't |
102 |
> > proper either. |
103 |
> > |
104 |
> > You want to indicate that this *specific* pkg costs money |
105 |
> > (something not related to the license it's released under I might |
106 |
> > add)? Stick it in metadata.xml or DESCRIPTION. |
107 |
> |
108 |
> Description is the worst place for it, IMO. I'd have no problem |
109 |
> sticking it in metadata.xml, either, but tell me how users are to get |
110 |
> that information? As it stands now, the only data in metadata.xml that |
111 |
> is used for *anything* is the herd/maintainer information, and that |
112 |
> information isn't available from portage, but only from external |
113 |
> 3rd-party applications and jeeves. |
114 |
|
115 |
|
116 |
>=2.1 portage supports querying from metadata.xml. Stable portage |
117 |
doesn't do a lot of things (like reading metadata.xml), but there's |
118 |
no reason later versions can't add in the missing |
119 |
functionality/feature. |
120 |
|
121 |
|
122 |
> > So... my 2 cents? No (was obvious already, wasn't it? :) |
123 |
> |
124 |
> Great. Give me another way to let the user know that the package |
125 |
> requires a purchase or obtaining a license that we cannot provide them. |
126 |
|
127 |
|
128 |
Gave you another way, and I also clarifed why this isn't just a bad |
129 |
idea, you _cannot_ do this. |
130 |
|
131 |
You view description as the wrong place for this; well, I view it as |
132 |
the proper place. License in no way relates to if the binaries/source |
133 |
must be purchased or not. |
134 |
|
135 |
It's a description thing. "ID's DOOM3 game, non shareware version" |
136 |
fex. Further, you're stating that "commercial" shouldn't be used as |
137 |
any form of grouping, but that _is_ what you're attempting- |
138 |
|
139 |
|
140 |
> If you do an "emerge -S doom3" on your system, how would you know that |
141 |
> the DOOM3 license is a commercial license? |
142 |
|
143 |
You read the license, silly, rather then blindly accepting licenses. |
144 |
The difference between doom3 and doom3-demo *should* be reflected in |
145 |
the DESCRIPTION also, since it's... the pkgs description data ;) |
146 |
|
147 |
The fields exist for what you're after; I don't know why you're after |
148 |
the abuse of the LICENSE field, but it won't fly without a heck of a |
149 |
lot more kicking/screaming from me, and a reversal/ammendment of |
150 |
glep23. |
151 |
|
152 |
Alternatives/better approaches I'd be open to, although I'll admit up |
153 |
front I think what you're attempting needs to be pkg specific, which |
154 |
implies DESCRIPTION in the ebuild (to me at least). |
155 |
~harring |