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

[Chris Gianelloni]

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
#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...
#9. a standardized api to connect to the soft-serve ice cream machine in
the developer lounge

I'm sure there's more, but these would be a godsend to have.  I'll be
sure to let you guys know if I can think of anything else.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux