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 <[EMAIL PROTECTED]> > wrote: > | 2. What choices/options are on the table for this feature? > > 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): > <snip> > > *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
needed down the line at some point- extension of depset syntax either
way isn't a hold up on true portage N repo support. Makes it a
helluva lot more useful, but just making it clear that N repo doesn't
require depset extension, such an extension would be a feature, not
a req.
Either way... minor comment on existing, and what's needed/intended.
Existing /etc/portage/package.* layout is inherintly single repo in
design- bastardizing the atom spec just to resolve that is daft.
What's needed is an extension of the portage configuration so that
it's able to specify multiple standalone repos, slaved (overlay) repos
chained against the standalones, package.* filters applied to each
repo, etc. Config design that's sitting in savior actually handles
this (eg, you can bind whatever crazy set of package.* visibility filters
you like per repo), *although* it _requires_ the user to uniquely
identify the repo. Why? Well portdir as a magic constant doesn't cut
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_
the local name that's bound to the repo, thus please stop the "user
configurable repo labels is stupid" angle, since it's effectively
the user facing alias/handle.
Local news delivery *should* still be using the user label. Unique
repo internal labels don't matter to glep42, since the label that news
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
up for glep42. What is an issue with glep42 is planning for N repos,
eg another level of dirs/indirection as has already been stated.
~harring
pgps1aZnnUTKY.pgp
Description: PGP signature
