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 |