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 ;) -- [email protected] mailing list
