1 |
On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina |
2 |
<zerochaos@g.o> wrote: |
3 |
> The user is distinguishing right from wrong by setting things like |
4 |
> USE=bindist, portage simply doesn't seem to be respecting that in the |
5 |
> case of RESTRICT=bindist. |
6 |
|
7 |
I think what is missing is a clear set of definitions. |
8 |
|
9 |
USE=-bindist means build a package that the maintainer thinks isn't |
10 |
legal to distribute under some set of circumstances (which might or |
11 |
might not be the user's circumstances). |
12 |
|
13 |
RESTRICT=bindist in an ebuild means what? Let's look at the devmanual: |
14 |
RESTRICT - A space-delimited list of portage features to restrict. |
15 |
Valid values are fetch, mirror, strip, testand userpriv. See man 5 |
16 |
ebuild for details. |
17 |
man 5 ebuild: |
18 |
bindist - Distribution of built packages is restricted. |
19 |
|
20 |
And how does a user tell portage whether they intend to redistribute |
21 |
something in the first place? The fact that an ebuild sets |
22 |
RESTRICT=bindist does not have anything to do with whether it will in |
23 |
fact be redistributed. It sounds like we would need a |
24 |
FEATURES=bindist to go along with it. Oh, and it sounds like |
25 |
RESTRICT=bindist often should be conditional based on USE=-bindist, |
26 |
but you can't set RESTRICT conditionally, so that won't work. |
27 |
|
28 |
Also, isn't all of this somewhat redundant with ACCEPT_LICENSE? It is |
29 |
the license that allows you to redistribute something in the first |
30 |
place, though with some licenses it might be conditional upon how the |
31 |
package is built/branded. |
32 |
|
33 |
The last thing we need on any of this stuff is a hard error. What is |
34 |
needed first is for those who care about such things to cleanly |
35 |
specify a sane set of definitions and behavior. |
36 |
|
37 |
Rich |