From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GMQnb-0007nh-1p for garchives@archives.gentoo.org; Sun, 10 Sep 2006 15:00:43 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8AEwoJ1014187; Sun, 10 Sep 2006 14:58:50 GMT Received: from mail.pnpitalia.it (85-18-21-122.ip.fastwebnet.it [85.18.21.122]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k8AEtLIT010610 for ; Sun, 10 Sep 2006 14:55:21 GMT Received: from localhost (localhost [127.0.0.1]) by mail.pnpitalia.it (Postfix) with ESMTP id 220307AD177 for ; Sun, 10 Sep 2006 16:55:21 +0200 (CEST) Received: from mail.pnpitalia.it ([127.0.0.1]) by localhost (db [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17243-13 for ; Sun, 10 Sep 2006 16:55:19 +0200 (CEST) Received: from [192.168.4.153] (host-4-153.pnpitalia.it [192.168.4.153]) by mail.pnpitalia.it (Postfix) with ESMTP id E42C07AD173 for ; Sun, 10 Sep 2006 16:55:18 +0200 (CEST) Message-ID: <450427ED.4070407@gentoo.org> Date: Sun, 10 Sep 2006 14:57:49 +0000 From: Francesco Riosa User-Agent: Thunderbird 1.5.0.5 (X11/20060806) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [RFC] Required Features for $package_manager to Aid... Development! References: <20060906102911.GD25413@gentoo.org> <1157809038.7667.17.camel@vertigo.twi-31o2.org> <45038D13.3010406@gentoo.org> In-Reply-To: <45038D13.3010406@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mail.pnpitalia.it X-Archives-Salt: 6069ccf7-e0c7-4d35-8397-46986b03b5f9 X-Archives-Hash: ae6bfdf015ac1401ff5773e5f67727d9 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') -- gentoo-dev@gentoo.org mailing list