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 1EnEUS-0007D9-Tr for garchives@archives.gentoo.org; Fri, 16 Dec 2005 12:15:13 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBGCEKw9028774; Fri, 16 Dec 2005 12:14:20 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 jBGCCQd9031720 for ; Fri, 16 Dec 2005 12:12:26 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1EnERk-0006O9-7X for gentoo-dev@lists.gentoo.org; Fri, 16 Dec 2005 07:12:24 -0500 X-ASG-Debug-ID: 1134735143-17852-122-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 9810F90577 for ; Fri, 16 Dec 2005 07:12:23 -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 jBGCCC5j021330 for ; Fri, 16 Dec 2005 12:12:12 GMT Date: Fri, 16 Dec 2005 04:12:08 -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: <20051216121208.GD30053@nightcrawler.e-centre.net> References: <43A235AD.6030604@leetworks.com> <20051216035630.2b005138@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="llIrKcgUOe3dCx0c" Content-Disposition: inline In-Reply-To: <20051216035630.2b005138@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.6355 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 527b1ca7-d61c-448c-9ac9-5111cb91e9ec X-Archives-Hash: 6eea6536178254810769617ee52678c6 --llIrKcgUOe3dCx0c Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 4am, pardon typos... On Fri, Dec 16, 2005 at 03:56:30AM +0000, Ciaran McCreesh wrote: > On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco > wrote: > | 2. What choices/options are on the table for this feature? >=20 > The big controversy seems to be over whether repositories carry a > unique identifier string (for example, in metadata/repository_id) or > whether it's user-assigned. The former is clearly the more sensible > option, since it lets you do things like (syntax made up): >=20 >=20 > *shrug* But it seems the Portage guys want repository names to be > user-assigned, which makes them far less useful. You seem confused. Unique repo ID added to atoms? Bit bastardly imo, but that's=20 needed down the line at some point- extension of depset syntax either=20 way isn't a hold up on true portage N repo support. Makes it a=20 helluva lot more useful, but just making it clear that N repo doesn't=20 require depset extension, such an extension would be a feature, not=20 a req. Either way... minor comment on existing, and what's needed/intended. Existing /etc/portage/package.* layout is inherintly single repo in=20 design- bastardizing the atom spec just to resolve that is daft. What's needed is an extension of the portage configuration so that=20 it's able to specify multiple standalone repos, slaved (overlay) repos=20 chained against the standalones, package.* filters applied to each=20 repo, etc. Config design that's sitting in savior actually handles=20 this (eg, you can bind whatever crazy set of package.* visibility filters= =20 you like per repo), *although* it _requires_ the user to uniquely=20 identify the repo. Why? Well portdir as a magic constant doesn't cut=20 it in a potentially N repo environment. Why is this a user configurable option? User's choice for emerge --repo ${repo_label} sync. This in no way blocks an internal repo ID being used- it's _merely_=20 the local name that's bound to the repo, thus please stop the "user=20 configurable repo labels is stupid" angle, since it's effectively=20 the user facing alias/handle. Local news delivery *should* still be using the user label. Unique=20 repo internal labels don't matter to glep42, since the label that news=20 delivery _should_ use is what the user's configuration has named it. Just stating it, since tagging a unique id into the repo isn't a hold=20 up for glep42. What is an issue with glep42 is planning for N repos,=20 eg another level of dirs/indirection as has already been stated. ~harring --llIrKcgUOe3dCx0c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDoq8YvdBxRoA3VU0RAtQgAJ9Iw69kIR7tUXIU4eSnMMEwq80EeQCfYjT0 rlwxcQpNiQQ7Xi7DpTjSisw= =5936 -----END PGP SIGNATURE----- --llIrKcgUOe3dCx0c-- -- gentoo-dev@gentoo.org mailing list