[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Should mirror restriction imply bindist restriction?
From:       "Rick \"Zero_Chaos\" Farina" <zerochaos () gentoo ! org>
Date:       2013-04-26 19:07:32
Message-ID: 517AD074.9080006 () gentoo ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 02:44 PM, Rich Freeman wrote:
> On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>> The user is distinguishing right from wrong by setting things like
>> USE=bindist, portage simply doesn't seem to be respecting that in the
>> case of RESTRICT=bindist.
> 
> I think what is missing is a clear set of definitions.
> 
> USE=-bindist means build a package that the maintainer thinks isn't
> legal to distribute under some set of circumstances (which might or
> might not be the user's circumstances).
> 
> RESTRICT=bindist in an ebuild means what?  Let's look at the devmanual:
> RESTRICT - A space-delimited list of portage features to restrict.
> Valid values are fetch, mirror, strip, testand userpriv. See man 5
> ebuild for details.
> man 5 ebuild:
> bindist - Distribution of built packages is restricted.
> 
> And how does a user tell portage whether they intend to redistribute
> something in the first place?  The fact that an ebuild sets
> RESTRICT=bindist does not have anything to do with whether it will in
> fact be redistributed.  It sounds like we would need a
> FEATURES=bindist to go along with it.  Oh, and it sounds like
> RESTRICT=bindist often should be conditional based on USE=-bindist,
> but you can't set RESTRICT conditionally, so that won't work.
> 
> Also, isn't all of this somewhat redundant with ACCEPT_LICENSE?  It is
> the license that allows you to redistribute something in the first
> place, though with some licenses it might be conditional upon how the
> package is built/branded.
> 
> The last thing we need on any of this stuff is a hard error.  What is
> needed first is for those who care about such things to cleanly
> specify a sane set of definitions and behavior.
> 
I really appreciate your input here, I think you may be onto something.
 Maybe the best thing to do would be to drop RESTRICT=bindist entirely
and just make a new license group for it? Maybe it would even be
possible to automatically ACCEPT_LICENSE=bindist when USE=-bindist and
vice-versa?  This seems a more productive direction than anything I was
able to come up with.

Thanks!
Zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRetB0AAoJEKXdFCfdEflKpJUP/jvGcTA7K+i/22ljUmVCqb5/
aVperRWG1lpPOoLWZHsZG8/ic9+F0O0gEYQEx4yBObZFQGU10D8DiLzVdyKh2J83
pxIC+pNC4vlgjAIznq1pl5YvIJ/JOmU3G05JIdxWYg17IGYDuy08IJc0g6LGSGpQ
dkNNdsAd8D3Xx9+SfFXl1cpzu8qfjzOubSdBpkdDuKR4fvorar4p9dT5ruWDW4KZ
Rt+n0DOSGyWSGpB0KNhOJIbkVjbW0oPnYmsosbmYkfF/dN0eYE9Zyb5E7hgOT9c6
WWF9Lg0f16xcjJS0RnZ/4PbzNYNfjIf/bx9KXfR5wQFpqEnhzK/oMqUs12JnHL3r
4mdzg/DG6jfBsO+IlyTP+2P4NUQVjSKZXC/gPDgSG4U7PpcE7ZtDqO+A/An3jxcG
5BBA1ZoTx4dEPLSqlau1+MKLIWQ2xl5ei8Y9PrWvZd0fGTZxwmWKb667AgyI94ar
83g6gprPM2EXnAyH1G0Krdt44aEccjfgjqyf0dOX/hUh64kvILxvdCrNxTqGjvQq
z2OkluSyzUF7cHa5MxOcqPaetDwsFdCeV85PJ3q0vPm//saLX6TlnD6bzB+ynNXl
JhZH+6qKbifIjPdVvq1GkXMDzF5/KSE6YUyHTXbQOhBBhLh6PgosE/81H1P55ZxG
lvcW5DWzwl72B7KkI8/9
=ssUj
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]