| 1 |
4am, pardon typos... |
| 2 |
|
| 3 |
On Fri, Dec 16, 2005 at 03:56:30AM +0000, Ciaran McCreesh wrote: |
| 4 |
> On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <tuxp3@×××××××××.com> |
| 5 |
> wrote: |
| 6 |
> | 2. What choices/options are on the table for this feature? |
| 7 |
> |
| 8 |
> The big controversy seems to be over whether repositories carry a |
| 9 |
> unique identifier string (for example, in metadata/repository_id) or |
| 10 |
> whether it's user-assigned. The former is clearly the more sensible |
| 11 |
> option, since it lets you do things like (syntax made up): |
| 12 |
> |
| 13 |
<snip> |
| 14 |
> |
| 15 |
> *shrug* But it seems the Portage guys want repository names to be |
| 16 |
> user-assigned, which makes them far less useful. |
| 17 |
|
| 18 |
You seem confused. |
| 19 |
|
| 20 |
Unique repo ID added to atoms? Bit bastardly imo, but that's |
| 21 |
needed down the line at some point- extension of depset syntax either |
| 22 |
way isn't a hold up on true portage N repo support. Makes it a |
| 23 |
helluva lot more useful, but just making it clear that N repo doesn't |
| 24 |
require depset extension, such an extension would be a feature, not |
| 25 |
a req. |
| 26 |
|
| 27 |
|
| 28 |
Either way... minor comment on existing, and what's needed/intended. |
| 29 |
|
| 30 |
Existing /etc/portage/package.* layout is inherintly single repo in |
| 31 |
design- bastardizing the atom spec just to resolve that is daft. |
| 32 |
|
| 33 |
What's needed is an extension of the portage configuration so that |
| 34 |
it's able to specify multiple standalone repos, slaved (overlay) repos |
| 35 |
chained against the standalones, package.* filters applied to each |
| 36 |
repo, etc. Config design that's sitting in savior actually handles |
| 37 |
this (eg, you can bind whatever crazy set of package.* visibility filters |
| 38 |
you like per repo), *although* it _requires_ the user to uniquely |
| 39 |
identify the repo. Why? Well portdir as a magic constant doesn't cut |
| 40 |
it in a potentially N repo environment. |
| 41 |
|
| 42 |
Why is this a user configurable option? |
| 43 |
|
| 44 |
User's choice for emerge --repo ${repo_label} sync. |
| 45 |
|
| 46 |
This in no way blocks an internal repo ID being used- it's _merely_ |
| 47 |
the local name that's bound to the repo, thus please stop the "user |
| 48 |
configurable repo labels is stupid" angle, since it's effectively |
| 49 |
the user facing alias/handle. |
| 50 |
|
| 51 |
Local news delivery *should* still be using the user label. Unique |
| 52 |
repo internal labels don't matter to glep42, since the label that news |
| 53 |
delivery _should_ use is what the user's configuration has named it. |
| 54 |
|
| 55 |
Just stating it, since tagging a unique id into the repo isn't a hold |
| 56 |
up for glep42. What is an issue with glep42 is planning for N repos, |
| 57 |
eg another level of dirs/indirection as has already been stated. |
| 58 |
|
| 59 |
~harring |
Archives