Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/04/13 03:07 PM, Rick "Zero_Chaos" Farina wrote:
> On 04/26/2013 02:44 PM, Rich Freeman wrote:
>> On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina
>> <zerochaos@g.o> 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
>
>

erm..  OK just to back up on things a little bit..:

IUSE="bindist" tends to be for adjusting a particular package so that
it either is generic and CAN be binary-distributable, or will build as
upstream intended (with, for instance, upstream branding) and
therefore is not.  Right?

So, in essence, the use flag can allow for an exception of a 'bindist'
LICENSE.  Would it make more sense then to have LICENSE= contents
controlled conditionally?  ie:

www-client/firefox:
LICENSE="MPL-2.0 GPL-2 LGPL-2.1
	!bindist? ( MPL-2.0-bindist-restriction )"

Of course for other packages there is no USE="bindist" functionality
as it's not possible to allow any binary redistribution.  These
probably should just go into the 'bindist' license group.

I think it would make a lot of sense to NOT let a use flag suddenly
adjust ACCEPT_LICENSE.  However, it -would- i think make a lot of
sense to ebuilds that implement a bindist use flag to adjust the
licenses that apply to the emerged result.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlF61FsACgkQ2ugaI38ACPBDIgEAj5QCD3sKZcrsQpaA/4OTRdfs
jlhH0owE4epqvYlHgqUBAJ+eUsKPUBfgnKK7MfzGhvzdACgnb1UlMJ4Ax35L8iKY
=kdJW
-----END PGP SIGNATURE-----