1 |
On 11/02/16 12:55, Rich Freeman wrote: |
2 |
> On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
>> On 11 February 2016 at 15:51, Rich Freeman <rich0@g.o> wrote: |
4 |
>>> In this case you just wouldn't enable python 2.7 support, but you |
5 |
>>> wouldn't disable it either. Portage would just pull it in where it is |
6 |
>>> needed. |
7 |
>> But you still need a mechanism in place if you *dont* want that to happen. |
8 |
>> ... |
9 |
>>> Unless of course you're suggesting "USE=-python_targets_python2_7" |
10 |
>> would not be "auto-enableable" |
11 |
> That is correct. |
12 |
> |
13 |
>> But then you're *still* requiring a tri-state USE. |
14 |
> Sure - it would be the same as how package-versions work today. |
15 |
> |
16 |
> Stick it in world, and you're pulling it in. |
17 |
> |
18 |
> Stick in in mask, and you're keeping it out. |
19 |
> |
20 |
> Don't do anything, and portage does what it thinks is best, guided by |
21 |
> profiles/etc. |
22 |
> |
23 |
>> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required |
24 |
> This is the only thing that would change. In all the other scenarios |
25 |
> you described the behavior would be the same as today. If you set |
26 |
> USE=-foo then you'll get the same errors you get today. |
27 |
> |
28 |
> Now, auto-unmask could still propose sticking USE=+foo in your |
29 |
> package.use if you have USE=-foo in your make.conf, which is already |
30 |
> the behavior today. If you've made any explicit USE setting in your |
31 |
> configuration, portage would never ignore it, but only suggest that |
32 |
> you change it. |
33 |
> |
34 |
> Perhaps it might make sense to introduce a new ~foo setting which |
35 |
> undoes a +/-foo in make.conf but doesn't set it either + or - in |
36 |
> package.use, allowing the setting to revert to the default behavior. |
37 |
> That would actually be useful independent of lazy use flags, but would |
38 |
> be more useful with lazy use flags. |
39 |
> |
40 |
>> Mentally keeping track of this accounting magic would be complicating matters. |
41 |
>> |
42 |
> I think you're overthinking this. It is completely analogous as to |
43 |
> what portage already does with package-versions. I don't have libjpeg |
44 |
> in my world file, and yet portage installs it, and I don't think about |
45 |
> it either way. If I wanted to pin a specific version of it or mask it |
46 |
> I could, but of course the preference of most users is to micromanage |
47 |
> as little as possible. |
48 |
> |
49 |
> Basically lazy use flags is intended for users to minimize the size of |
50 |
> their package.use files, just as they already minimize the size of |
51 |
> their @world and package.mask files today. |
52 |
> |
53 |
I would avoid complicating the USE flag system .. it's straightforward |
54 |
as it is, and has already been 'tweaked' by the auto-unmask feature, |
55 |
leading to large package.use files and has no support of per-category |
56 |
files (that I know of). |
57 |
|
58 |
I would propose the introduction of a 'LUSE' flag (lazy-use or |
59 |
lightweight-use) which serves as a fall-back if the main USE system |
60 |
"fails" - ok this requires duplication of the existing checking system |
61 |
(and hence integration with portage) but it would allow you to set USE |
62 |
flags per system at install .. and you could 'tweak' LUSE flags to suit |
63 |
package implementations instead. |