| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 04/26/2013 02:44 PM, Rich Freeman wrote: |
| 5 |
> On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina |
| 6 |
> <zerochaos@g.o> wrote: |
| 7 |
>> The user is distinguishing right from wrong by setting things like |
| 8 |
>> USE=bindist, portage simply doesn't seem to be respecting that in the |
| 9 |
>> case of RESTRICT=bindist. |
| 10 |
> |
| 11 |
> I think what is missing is a clear set of definitions. |
| 12 |
> |
| 13 |
> USE=-bindist means build a package that the maintainer thinks isn't |
| 14 |
> legal to distribute under some set of circumstances (which might or |
| 15 |
> might not be the user's circumstances). |
| 16 |
> |
| 17 |
> RESTRICT=bindist in an ebuild means what? Let's look at the devmanual: |
| 18 |
> RESTRICT - A space-delimited list of portage features to restrict. |
| 19 |
> Valid values are fetch, mirror, strip, testand userpriv. See man 5 |
| 20 |
> ebuild for details. |
| 21 |
> man 5 ebuild: |
| 22 |
> bindist - Distribution of built packages is restricted. |
| 23 |
> |
| 24 |
> And how does a user tell portage whether they intend to redistribute |
| 25 |
> something in the first place? The fact that an ebuild sets |
| 26 |
> RESTRICT=bindist does not have anything to do with whether it will in |
| 27 |
> fact be redistributed. It sounds like we would need a |
| 28 |
> FEATURES=bindist to go along with it. Oh, and it sounds like |
| 29 |
> RESTRICT=bindist often should be conditional based on USE=-bindist, |
| 30 |
> but you can't set RESTRICT conditionally, so that won't work. |
| 31 |
> |
| 32 |
> Also, isn't all of this somewhat redundant with ACCEPT_LICENSE? It is |
| 33 |
> the license that allows you to redistribute something in the first |
| 34 |
> place, though with some licenses it might be conditional upon how the |
| 35 |
> package is built/branded. |
| 36 |
> |
| 37 |
> The last thing we need on any of this stuff is a hard error. What is |
| 38 |
> needed first is for those who care about such things to cleanly |
| 39 |
> specify a sane set of definitions and behavior. |
| 40 |
> |
| 41 |
I really appreciate your input here, I think you may be onto something. |
| 42 |
Maybe the best thing to do would be to drop RESTRICT=bindist entirely |
| 43 |
and just make a new license group for it? Maybe it would even be |
| 44 |
possible to automatically ACCEPT_LICENSE=bindist when USE=-bindist and |
| 45 |
vice-versa? This seems a more productive direction than anything I was |
| 46 |
able to come up with. |
| 47 |
|
| 48 |
Thanks! |
| 49 |
Zero |
| 50 |
|
| 51 |
-----BEGIN PGP SIGNATURE----- |
| 52 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 53 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 54 |
|
| 55 |
iQIcBAEBAgAGBQJRetB0AAoJEKXdFCfdEflKpJUP/jvGcTA7K+i/22ljUmVCqb5/ |
| 56 |
aVperRWG1lpPOoLWZHsZG8/ic9+F0O0gEYQEx4yBObZFQGU10D8DiLzVdyKh2J83 |
| 57 |
pxIC+pNC4vlgjAIznq1pl5YvIJ/JOmU3G05JIdxWYg17IGYDuy08IJc0g6LGSGpQ |
| 58 |
dkNNdsAd8D3Xx9+SfFXl1cpzu8qfjzOubSdBpkdDuKR4fvorar4p9dT5ruWDW4KZ |
| 59 |
Rt+n0DOSGyWSGpB0KNhOJIbkVjbW0oPnYmsosbmYkfF/dN0eYE9Zyb5E7hgOT9c6 |
| 60 |
WWF9Lg0f16xcjJS0RnZ/4PbzNYNfjIf/bx9KXfR5wQFpqEnhzK/oMqUs12JnHL3r |
| 61 |
4mdzg/DG6jfBsO+IlyTP+2P4NUQVjSKZXC/gPDgSG4U7PpcE7ZtDqO+A/An3jxcG |
| 62 |
5BBA1ZoTx4dEPLSqlau1+MKLIWQ2xl5ei8Y9PrWvZd0fGTZxwmWKb667AgyI94ar |
| 63 |
83g6gprPM2EXnAyH1G0Krdt44aEccjfgjqyf0dOX/hUh64kvILxvdCrNxTqGjvQq |
| 64 |
z2OkluSyzUF7cHa5MxOcqPaetDwsFdCeV85PJ3q0vPm//saLX6TlnD6bzB+ynNXl |
| 65 |
JhZH+6qKbifIjPdVvq1GkXMDzF5/KSE6YUyHTXbQOhBBhLh6PgosE/81H1P55ZxG |
| 66 |
lvcW5DWzwl72B7KkI8/9 |
| 67 |
=ssUj |
| 68 |
-----END PGP SIGNATURE----- |
Archives