Alec Warner wrote:
> Chris Gianelloni wrote:
>> On Wed, 2006-09-06 at 21:19 -0600, Ryan Hill wrote:
>>> Elfyn McBratney wrote:
>>>
>>>> I've been inspired by the local/global USE flag threads recently
>>>> posted by Doug (Cardoe), and it got me to thinking... I've recently
>>>> joined the pkgcore development effort, and was asked by Brian
>>>> (ferringb) what I'd like to hack on/what my niggles with portage are.
>>>> My personal one is why updates/ and binpkg mangling takes so long in
>>>> portage-$current. But I'd like to know, what are everyone elses?
>>> I've been thinking about this lately too. I think it would be a good
>>> idea to come up with as many different use cases as we can think of and
>>> figure out what we can already do, what we would like to do, and the
>>> best way to do it.
>>>
>>>> I know that this topic have been rehashed since the dawn of
>>>> time^Wgentoo-dev, but these things get lost, opinions change... and
>>>> since last year, new and viable alternate package managers have
>>>> cropped up. So, basically I'd like to ask all on this list: - what
>>>> package manager features would make *your* life easier?
>>> - current pet peeve is some way of dealing with SRC_URI's that use
>>> dynamic redirects to the source files (eg.
>>> http://nwvault.ign.com/fms/Download.php?id=57167 ->
>>> http://someserver.com/randomlygeneratedhashthatchangeseveryhour/the_HeX_coda_01_v1.3.zip).
>>>
>>> Since the name of the file fetched (the_HeX_coda_01_v1.3.zip) != the
>>> one in SRC_URI (Download.php?id=57167) portage bombs. right now i have
>>> to use RESTRICT="fetch" which sucks.
>> There's also any SRC_URI that includes an "&"...
>>
>> There are some things that I would like to see from a Release
>> Engineering standpoint. These are things that I would like some way to
>> obtain, not necessarily from the normal user "front-end" to
>> $package_manager, but somehow.
>>
>> #1. Ability to grab USE from the environment for a machine both before
>> and after USE_EXPAND is calculated
>> #2. Ability to ignore environment's USE when doing calculations, such as
>> the easily grabbing the contents of the "system" target with the default
>> USE for a profile
>
> This is possible via USE_ORDER, you can turn whatever stacking you like
> on or off. It's usage is not supported (as in you break it you fix it);
> mostly this is to prevent users from futzing with USE_ORDER and then
> complaining to us about it.
>
>> #3. Ability to list the stable package versions for a given profile
>> #4. Ability to list the testing package versions for a given profile
>> #5. Ability to list the used USE flags in a given set of packages
>> #6. Ability to list the licenses used in a given set of packages (this
>> is especially important as we are seeing more and more packages that we
>> are not allowed to redistribute being used accidentally)
>> #7. Ability to list the packages that use a given set of licenses
>> #8. Ability to list the dependency tree for packages, even if some of
>> the dependencies are masked by keywords, rather than throwing up the
>> "this package is masked by keywords" error for each one, allowing one to
>> see *quickly* all of the packages that need keyword changes for a
>> particular package to have its keywords changed... fex. "emerge
>> --keywords =kde-base/kde-4.0" should list all of KDE 4.0's dependencies,
>> and anything that is masked by keywords should show up as "~" or
>> something... anything masked by package.mask should show up as "M"...
>> this should have a way of choosing to ignore profile-level masks or not,
>> also... this is just an example, how we actually get the information
>> doesn't matter, so long as we can get it...
>
> This is a tricky one (and often asked for!). The output would be a
> guess at best though.
>
> A : Depends on B
> B-1 : Depends on C
> B-2 : Depends on C,D,E
>
> All versions of B are masked; so either you get
>
> A
> ~B (Warning B is masked)
>
> or you get
>
> A
> ~B (Warning B is masked)
> C
>
> or
>
> A
> ~B (Warning B is masked)
> C
> D
> E
>
> This depends of course on which version of B we choose. This is why
> this request isn't implemented; there is no good heuristic for making
> this choice and in complex dependency trees, bad choices lead to bad
> results.
What about to decide for the less dangerous, less keywording route ?
follow pseudo-pseudo-code:
def find_all_dependants_recursive(\
pkg, \
acceptable_version_range='0..inf', \
already_needed={}, \
recursion_level=0 \
)
SELECT p.version, p.stability, p.depends
INTO %p_version, %p_stable_level, %p_depends
FROM packages AS p
WHERE p.version BETWEEN %acceptable_version_range
ORDER BY p.version DESC, p.stability
LIMIT 1
if already_needed.has_key(pkg):
"""
already encountered this package,
check that current needs are ok
"""
if \ %p_version.inside(already_needed[pkg]['acceptable_version_range']):
"""
TOCHECK:
the range is compatible, do nothing ?
"""
pass
else:
# damn, we need to try harder to look if there is a good
# package version
if \
already_needed[pkg]['acceptable_version_range'].inside(acceptable_version_range):
# we can try the luck
already_needed[pkg] = find_a_good_one(\
pkg, \
already_needed[pkg]['acceptable_version_range']
)
else:
# there is no possibility to find a good package,
# the tree is broken
throw_error,_clean_and_die()
else:
already_needed[pkg] = {\
'acceptable_version_range' : acceptable_version_range, \
'version' : %p_version, \
'stable_level' : %p_stable_level \
}
for dpkg in %p_depends:
find_all_dependants_recursive(\
%p_depends['pkg'], \
%p_depends['acceptable_version_range'], \
already_needed, \
recursion_level +1 \
)
if recursion_level == 0:
einfo('yay')
return already_needed
return 42
def find_a_good_one(pkg, acceptable_version_range)
SELECT p.version, p.stability, p.depends
INTO %p_version, %p_stable_level
FROM packages AS p
WHERE p.version BETWEEN %acceptable_version_range
ORDER BY p.version DESC, p.stability
LIMIT 1
return {\
'acceptable_version_range' : acceptable_version_range, \
'version' : %p_version, \
'stable_level' : %p_stable_level \
}
if __name__ == "__main__":
print find_all_dependants_recursive('dev-db/i_am_a_bad_puppy')
--
[email protected] mailing list
