Gentoo Archives: gentoo-dev

From: Kent Fredric <kentfredric@×××××.com>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] "Lazy" use flags?
Date: Thu, 11 Feb 2016 14:26:09
Message-Id: CAATnKFASFPhJLx_W4b8TKNeoNeG4Dw0UYLpUC0OrbYMf7xp-dQ@mail.gmail.com
In Reply to: Re: [gentoo-dev] "Lazy" use flags? by NP-Hardass
1 On 12 February 2016 at 02:54, NP-Hardass <NP-Hardass@g.o> wrote:
2 > Just a slightly OT side note...
3
4 Quite, these are the *sorts* of things I've been mulling over for a
5 bit without coming to a concrete implementation idea.
6
7 > I split mine off into a separate file (using a directory for package.use
8 > ).
9 > I proposed a feature a while back,
10 > https://bugs.gentoo.org/show_bug.cgi?id=534548, where all use flags
11 > are stored in /etc/portage/package.use/${USE_EXPAND} to help with
12 > management.
13
14 My experience so far has been similar, in that clustering settings
15 based on the setting tends to be a good primary classifier.
16
17 Though I maintain 2 different layout structures depending on task:
18
19 Scheme 1 I use for package.use and keywords and stuff:
20
21 package.use/01-${cat} # contains use settings for all packages in ${cat}
22 package.use/90-${task} # contains all settings for use flags that
23 achieve a single "task" ( like I have an entire file just for the
24 legacy abi_x86_32 support )
25 package.use/99-autounmask # because auto-unmask writes to the last
26 file alphabetically, so garbage goes in here if I ever make the
27 mistake of using autounmask-write again
28
29 Scheme 2 I use for package.env
30
31 package.env/${task}/${pn}
32
33 Where "$task" is as above, but "${pn}" is the program-in-world-I-want,
34 and the file contains settings that achieve "task" for its
35 dependencies.
36
37 This is me trying to approximate a "Lazy" graph, as each entry named
38 "${pn}" says:
39
40 <=cat/pn-$version py2.7
41
42 # deps
43 cat/pn py2.7
44 cat/pn py2.7
45
46 That way, every time an update to ${pn} happens where it still needs
47 the old python, it cries about it, but in the future it will be
48 trivial to check "packages I have installed" vs "lazy rule files I
49 have" and see when the condition is no longer required, and I can
50 simply reap the whole file. ( This is kinda hell because of all the
51 overlapping dependencies, but its better than nothing )
52
53
54 > Yet another feature similar to lazy eval of use flags is another bug I
55 > created a while back, recommended and conditional use flags
56 > https://bugs.gentoo.org/show_bug.cgi?id=539124.
57
58 recommended I wanted too, but I figured it would be easy enough to
59 bodge around it with:
60
61 IUSE="minimal suggested feature"
62 DEPEND="!minimal? ( feature_dep )
63 feature? ( feature_dep )
64 "
65
66 Or something like that. ( using the word "minimal" as a stand in for
67 "don't pull recommended stuff" because that's already a global
68 useflag, and under the assumption that the words "recommended" implies
69 "Installed by default" )
70
71 But in the feature as stated, there's a bit of a gap conceptually,
72 because sometimes upstream produce a set of dependencies with no
73 description other than "these are all recommended deps and you should
74 have all of them, unless you're working in very constrained
75 circumstances and you know what you're doing, and things may break in
76 certain code paths if you don't install them", and "RECOMMENDED_USE"
77 here doesn't exactly cover that featureset. You'd still need an
78 explicit "minimal" for that.
79
80 Conditional I kinda thought about and decided "naah, too complex,
81 you'll blow any resolver up with that stuff" .
82
83 Though we may be wanting different things entirely in "recommended
84 useflags", because I'm riffing more on "recommended dependencies"
85 which may incidentally be "dependencies required by this package if a
86 certain package is to use it", and the only way to communicate that
87 between packages at present is with "cat-egory/pakc-1.2[-minimal]"
88
89 --
90 Kent
91
92 KENTNL - https://metacpan.org/author/KENTNL