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

[Rick \\\"Zero_Chaos\\\" Farina]

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

On 04/26/2013 03:24 PM, Ian Stakenvicius wrote:
> 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 )"

It was not my intention to switch valid licenses based on a use flag.
I'm pretty sure that isn't valid and the same license applies whether or
not you are going to redistribute it, the license doesn't change.

For the packages which already have USE=bindist they are conditionally
restricting binary redistribution and that is already handled well.  The
issue is that nothing prevents (or even really alerts) the user in the
case of things which are ALWAYS restricted.  Honestly I'm very happy
with the current USE=bindist behavior, I'm not happy with RESTRICT=bindist.

Based on Rich's suggestion my thought is have a new license group for
things which are ALWAYS binary restricted, accepted by default, but
removed from ACCEPT_LICENSE when USE=bindist.  That is just what is
rolling around in my head right now, but it is semi-sane.

Thanks,
Zero
>
> 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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRetj8AAoJEKXdFCfdEflKsdwP/3z7yFPpZm3zBynGzNNuviyz
pq1svrwZQL82gptTQoWt+/KyLGu+1sHgW4nLW7mPSzYbLWiu+/1fyOQWcAhQT2j8
kGW5vlLgz5Mb7SJWNEP0xcHtV3/OZPWj5KkKrsmjka4qf69XJ9KAXDka0joxO05O
uXAxzhAbaODKlmAF4oMqpNuEVmFTxk+hko05m4tIxTD1MbTBys8UR7EwwdcqZCTP
nVkDEanwgIOrVwc18t4DRr7gKkPc/dbcr9GYQtWlywPdQpUBfkdwaFCTk/gG6FQ+
Sq/3LLciU2+8JZgq1tROwYYboxXPNTjIE3KRxViIWddPo4/sZnrU+bv53zvusduw
t4WZ5ODZRttM+M/8Hx5E30EhMP5hF8IqvsxFYNNQJGcJa5B6vPMh1jK7TV9srGNx
IJkmufYR2SApzpBdn4Sx6VVmjSwpEOrCzNyNg029Zdrmlg+Ggv9h6YV7J05TCDhU
bCdeIP9Kq2IlZkVjLOJeDp8gS7hJpUvqH2Ky9wophbikTbQjnDVhBGlK9+WW4K5z
bH0MKRJCh4j3YqIlPyvIct2BH1Lzbh0O2ztB2w74AmE1INvuwtRdpUQLxGMr1XO+
9tOeIH/80dyseJSRCBULSlHtNqudM/0x15SIpJ6kxvTn5oZjC8uG8/rI6JbeY3OD
9lGtUSiLLys5mK1BFCR2
=vtqG
-----END PGP SIGNATURE-----