1 |
Alec Warner wrote: |
2 |
> Chris Gianelloni wrote: |
3 |
>> On Wed, 2006-09-06 at 21:19 -0600, Ryan Hill wrote: |
4 |
>>> Elfyn McBratney wrote: |
5 |
>>> |
6 |
>>>> I've been inspired by the local/global USE flag threads recently |
7 |
>>>> posted by Doug (Cardoe), and it got me to thinking... I've recently |
8 |
>>>> joined the pkgcore development effort, and was asked by Brian |
9 |
>>>> (ferringb) what I'd like to hack on/what my niggles with portage are. |
10 |
>>>> My personal one is why updates/ and binpkg mangling takes so long in |
11 |
>>>> portage-$current. But I'd like to know, what are everyone elses? |
12 |
>>> I've been thinking about this lately too. I think it would be a good |
13 |
>>> idea to come up with as many different use cases as we can think of and |
14 |
>>> figure out what we can already do, what we would like to do, and the |
15 |
>>> best way to do it. |
16 |
>>> |
17 |
>>>> I know that this topic have been rehashed since the dawn of |
18 |
>>>> time^Wgentoo-dev, but these things get lost, opinions change... and |
19 |
>>>> since last year, new and viable alternate package managers have |
20 |
>>>> cropped up. So, basically I'd like to ask all on this list: - what |
21 |
>>>> package manager features would make *your* life easier? |
22 |
>>> - current pet peeve is some way of dealing with SRC_URI's that use |
23 |
>>> dynamic redirects to the source files (eg. |
24 |
>>> http://nwvault.ign.com/fms/Download.php?id=57167 -> |
25 |
>>> http://someserver.com/randomlygeneratedhashthatchangeseveryhour/the_HeX_coda_01_v1.3.zip). |
26 |
>>> Since the name of the file fetched (the_HeX_coda_01_v1.3.zip) != the |
27 |
>>> one in SRC_URI (Download.php?id=57167) portage bombs. right now i have |
28 |
>>> to use RESTRICT="fetch" which sucks. |
29 |
>> There's also any SRC_URI that includes an "&"... |
30 |
>> |
31 |
>> There are some things that I would like to see from a Release |
32 |
>> Engineering standpoint. These are things that I would like some way to |
33 |
>> obtain, not necessarily from the normal user "front-end" to |
34 |
>> $package_manager, but somehow. |
35 |
>> |
36 |
>> #1. Ability to grab USE from the environment for a machine both before |
37 |
>> and after USE_EXPAND is calculated |
38 |
>> #2. Ability to ignore environment's USE when doing calculations, such as |
39 |
>> the easily grabbing the contents of the "system" target with the default |
40 |
>> USE for a profile |
41 |
> |
42 |
> This is possible via USE_ORDER, you can turn whatever stacking you like |
43 |
> on or off. It's usage is not supported (as in you break it you fix it); |
44 |
> mostly this is to prevent users from futzing with USE_ORDER and then |
45 |
> complaining to us about it. |
46 |
> |
47 |
>> #3. Ability to list the stable package versions for a given profile |
48 |
>> #4. Ability to list the testing package versions for a given profile |
49 |
>> #5. Ability to list the used USE flags in a given set of packages |
50 |
>> #6. Ability to list the licenses used in a given set of packages (this |
51 |
>> is especially important as we are seeing more and more packages that we |
52 |
>> are not allowed to redistribute being used accidentally) |
53 |
>> #7. Ability to list the packages that use a given set of licenses |
54 |
>> #8. Ability to list the dependency tree for packages, even if some of |
55 |
>> the dependencies are masked by keywords, rather than throwing up the |
56 |
>> "this package is masked by keywords" error for each one, allowing one to |
57 |
>> see *quickly* all of the packages that need keyword changes for a |
58 |
>> particular package to have its keywords changed... fex. "emerge |
59 |
>> --keywords =kde-base/kde-4.0" should list all of KDE 4.0's dependencies, |
60 |
>> and anything that is masked by keywords should show up as "~" or |
61 |
>> something... anything masked by package.mask should show up as "M"... |
62 |
>> this should have a way of choosing to ignore profile-level masks or not, |
63 |
>> also... this is just an example, how we actually get the information |
64 |
>> doesn't matter, so long as we can get it... |
65 |
> |
66 |
> This is a tricky one (and often asked for!). The output would be a |
67 |
> guess at best though. |
68 |
> |
69 |
> A : Depends on B |
70 |
> B-1 : Depends on C |
71 |
> B-2 : Depends on C,D,E |
72 |
> |
73 |
> All versions of B are masked; so either you get |
74 |
> |
75 |
> A |
76 |
> ~B (Warning B is masked) |
77 |
> |
78 |
> or you get |
79 |
> |
80 |
> A |
81 |
> ~B (Warning B is masked) |
82 |
> C |
83 |
> |
84 |
> or |
85 |
> |
86 |
> A |
87 |
> ~B (Warning B is masked) |
88 |
> C |
89 |
> D |
90 |
> E |
91 |
> |
92 |
> This depends of course on which version of B we choose. This is why |
93 |
> this request isn't implemented; there is no good heuristic for making |
94 |
> this choice and in complex dependency trees, bad choices lead to bad |
95 |
> results. |
96 |
|
97 |
What about to decide for the less dangerous, less keywording route ? |
98 |
follow pseudo-pseudo-code: |
99 |
|
100 |
def find_all_dependants_recursive(\ |
101 |
pkg, \ |
102 |
acceptable_version_range='0..inf', \ |
103 |
already_needed={}, \ |
104 |
recursion_level=0 \ |
105 |
) |
106 |
|
107 |
SELECT p.version, p.stability, p.depends |
108 |
INTO %p_version, %p_stable_level, %p_depends |
109 |
FROM packages AS p |
110 |
WHERE p.version BETWEEN %acceptable_version_range |
111 |
ORDER BY p.version DESC, p.stability |
112 |
LIMIT 1 |
113 |
|
114 |
if already_needed.has_key(pkg): |
115 |
""" |
116 |
already encountered this package, |
117 |
check that current needs are ok |
118 |
""" |
119 |
|
120 |
if \ %p_version.inside(already_needed[pkg]['acceptable_version_range']): |
121 |
""" |
122 |
TOCHECK: |
123 |
the range is compatible, do nothing ? |
124 |
""" |
125 |
pass |
126 |
else: |
127 |
# damn, we need to try harder to look if there is a good |
128 |
# package version |
129 |
if \ |
130 |
already_needed[pkg]['acceptable_version_range'].inside(acceptable_version_range): |
131 |
# we can try the luck |
132 |
already_needed[pkg] = find_a_good_one(\ |
133 |
pkg, \ |
134 |
already_needed[pkg]['acceptable_version_range'] |
135 |
) |
136 |
else: |
137 |
# there is no possibility to find a good package, |
138 |
# the tree is broken |
139 |
throw_error,_clean_and_die() |
140 |
else: |
141 |
already_needed[pkg] = {\ |
142 |
'acceptable_version_range' : acceptable_version_range, \ |
143 |
'version' : %p_version, \ |
144 |
'stable_level' : %p_stable_level \ |
145 |
} |
146 |
|
147 |
for dpkg in %p_depends: |
148 |
|
149 |
find_all_dependants_recursive(\ |
150 |
%p_depends['pkg'], \ |
151 |
%p_depends['acceptable_version_range'], \ |
152 |
already_needed, \ |
153 |
recursion_level +1 \ |
154 |
) |
155 |
|
156 |
if recursion_level == 0: |
157 |
einfo('yay') |
158 |
return already_needed |
159 |
|
160 |
return 42 |
161 |
|
162 |
|
163 |
def find_a_good_one(pkg, acceptable_version_range) |
164 |
SELECT p.version, p.stability, p.depends |
165 |
INTO %p_version, %p_stable_level |
166 |
FROM packages AS p |
167 |
WHERE p.version BETWEEN %acceptable_version_range |
168 |
ORDER BY p.version DESC, p.stability |
169 |
LIMIT 1 |
170 |
|
171 |
return {\ |
172 |
'acceptable_version_range' : acceptable_version_range, \ |
173 |
'version' : %p_version, \ |
174 |
'stable_level' : %p_stable_level \ |
175 |
} |
176 |
|
177 |
|
178 |
if __name__ == "__main__": |
179 |
print find_all_dependants_recursive('dev-db/i_am_a_bad_puppy') |
180 |
|
181 |
-- |
182 |
gentoo-dev@g.o mailing list |