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.54) id 1EnkK9-00085X-Lt for garchives@archives.gentoo.org; Sat, 17 Dec 2005 22:14:42 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBHMDxOu019734; Sat, 17 Dec 2005 22:13:59 GMT Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBHMCBgw025227 for ; Sat, 17 Dec 2005 22:12:12 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1EnkHh-0002AO-9K for gentoo-dev@lists.gentoo.org; Sat, 17 Dec 2005 17:12:09 -0500 X-ASG-Debug-ID: 1134857528-18960-17-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-pdx-2.site.stayonline.net (unknown [65.200.64.131]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id B39E5C3FE6 for ; Sat, 17 Dec 2005 17:12:08 -0500 (EST) Received: from nightcrawler ([172.16.1.202]) by et-pdx-2.site.stayonline.net (8.12.6/8.12.6) with ESMTP id jBHMBq5j012162 for ; Sat, 17 Dec 2005 22:11:57 GMT Date: Sat, 17 Dec 2005 14:11:42 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Multiple Repo Support Subject: Re: [gentoo-dev] Multiple Repo Support Message-ID: <20051217221142.GA22142@nightcrawler.e-centre.net> References: <20051216175817.65682c34@snowdrop.home> <43A32F35.1020803@gmail.com> <20051216213353.5488df83@snowdrop.home> <43A33CE9.4090407@gmail.com> <20051216222705.62485e5c@snowdrop.home> <43A367C0.2040200@gmail.com> <43A47740.5040107@gmail.com> <20051217205039.04178471@snowdrop.home> <43A48014.1080000@gmail.com> <20051217212145.34372458@snowdrop.home> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20051217212145.34372458@snowdrop.home> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.6390 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 5f95c805-2ece-4415-b383-903e447c62e3 X-Archives-Hash: 78859f15c35970d4301eb85b6cafcea6 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 17, 2005 at 09:21:45PM +0000, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico wrote: > | Ciaran McCreesh wrote: > | > Well, that depends... If you have sys-apps/foo installed from the > | > gentoo-x86 repository, and the breakmygentoo repository issues a > | > news item about sys-apps/foo, should it be displayed? > |=20 > | Well, probably not. Off hand, perhaps portageq could provide a query > | that returns some type of UUID for a package, such as a hash of the > | ebuild. That way, the hash from /var/db/pkg could be compared to the > | hash from the repo that has the news item. If the hashes don't > | match, then the news item is irrelevant. >=20 > Now do you see why I don't want to touch multi repo support without a > proper specification describing how it'll work? :) Multi repo support is actually pretty simple, and doesn't require yet=20 another glep/spec/paperwork- it's been sitting in the saviour branch=20 for as long as the domain class has existed (3+ months); stand alone=20 repository support (matching within that repo) is a resolver thing,=20 where we're at in saviour is normal PORTDIR capabilities for all=20 specified repo's (standalone, overlay, or otherwise). It's not that bloody hard to get it working- all of the noise here is=20 about further additions to it (which is fine, but kindly rememeber=20 that fact), noise which I'd *rather* see resolved down the line. Why? =20 Frankly, the majority of this is portage internal crap. Either=20 extension of portageq api, or extension of atom syntax. Unique ID's per packages isn't a good idea offhand. What's needed for=20 the comments above is the ability to search installed pkg db's for=20 pkgs yielded from repo ID x. Enter the restriction subsystem. Add a=20 repo level matching class, and you've got the search right there. =20 Pretty simple, actually, and not requiring yet another glep for=20 saviour. Back in the land of stable, here's how it should be done- portageq root atom [repo id] ex: portageq / sys-apps/foo "break my gentoo" simple mod. Lack of repo id is old rules, match anything and=20 everything. This actually can be implemented *now* without requiring=20 a bunch of handwaving about specs/gleps. Next issue? ~harring --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDpI0evdBxRoA3VU0RAlZLAJ9PCmmFnFiyZQ3JJ6cZBnIyD7R7bQCfRzkW mqze7FHDxoakC7xi+hu0P+U= =gbIq -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- -- gentoo-dev@gentoo.org mailing list