Gentoo Archives: gentoo-dev

From: Ulrich Mueller <ulm@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] The bindist USE flag and RESTRICT=bindist
Date: Tue, 03 Mar 2015 21:12:18
Message-Id: 21750.9127.173258.547995@a1i15.kph.uni-mainz.de
1 Hi,
2 We currently have two mechanisms to influence building of packages
3 that cannot be binary redistributed. Some 150 packages have
4 RESTRICT=bindist (unconditional, or USE conditional), whereas
5 27 packages have the bindist flag in their IUSE. Until very recently,
6 the two sets were practically disjoint, with only one single package
7 (www-client/chromium) in both sets.
8
9 As a consequence, neither building with the well-known USE=bindist nor
10 with ACCEPT_RESTRICT="* -bindist" (presumably less known and Portage
11 only?) will guarantee that only redistributable binaries will be
12 built [1].
13
14 So a few days ago I filed bug 541408 and dependent bugs, with the goal
15 that ebuilds with the bindist flag in their IUSE should also add
16 RESTRICT="!bindist? ( bindist )". However, it turned out that some 10
17 packages are using the bindist flag only in REQUIRED_USE but nowhere
18 else [2] (with foo being some feature flag):
19
20 IUSE="bindist foo"
21 REQUIRED_USE="bindist? ( !foo )"
22
23 IMHO, the bindist USE flag is redundant in these cases. So we should
24 get rid of the REQUIRED_USE and add a restriction instead:
25
26 IUSE="foo"
27 RESTRICT="foo? ( bindist )"
28
29 What do you think? Should we proceed in this direction?
30
31 While discussing the issue in #-releng, it was also suggested that a
32 news item should be prepared, to inform users that they cannot rely on
33 USE=bindist. (They cannot rely on it already now, though.) Does it
34 make sense to have a news item for this?
35
36 Ulrich
37
38
39 [1] We also have some 300 packages that are mirror restricted but not
40 bindist restricted. It is likely that at least for part of them
41 binaries cannot be redistributed either. That is a separate issue,
42 though.
43 [2] Thanks to aballier for pointing this out in bug 541588.

Replies