Re: [gentoo-dev] Re: [RFC] Required Features for $package_manager to Aid... Development!

[Alec Warner]

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.

One of these days I will write these damn explanations down ;)
-- 
gentoo-dev@g.o mailing list