| 1 |
On Sun, 23 Jul 2006 12:19:28 +0100 |
| 2 |
Stuart Herbert <stuart@g.o> wrote: |
| 3 |
|
| 4 |
> Kevin F. Quinn wrote: |
| 5 |
> > An advantage to this approach is that package moves just become |
| 6 |
> > aliases |
| 7 |
> > - existing stuff doesn't break yet you get the new categorisation as |
| 8 |
> > well. |
| 9 |
> |
| 10 |
> That's actually a disadvantage. The whole point of moving a package |
| 11 |
> is to take it *out* of its existing category. |
| 12 |
|
| 13 |
No, the point is to take it from a category where it's membership is |
| 14 |
not so strong, to one where it is stronger. For exmaple, it's not that |
| 15 |
net-im is the wrong place for skype, it's just that net-voip is in some |
| 16 |
ways better. Where categorisation is clearly very wrong then it should |
| 17 |
be moved as soon as possible (for example if skype had initially been |
| 18 |
placed in www-apps) but that's an initial commit problem rather than |
| 19 |
maintenance going forward. |
| 20 |
|
| 21 |
> Just adding an alias |
| 22 |
> into a second category makes the tree more of a mess - not less. |
| 23 |
|
| 24 |
The alias, once setup, can be left alone forever. As far as any |
| 25 |
further maintenance is concerned, it requires none. Even if the |
| 26 |
package is moved again, the alias can still point to the second |
| 27 |
location which becomes an alias for the final location. As far as |
| 28 |
users are concerned, assuming aliases are resolved when being parsed, |
| 29 |
they would see: |
| 30 |
|
| 31 |
$ emerge -p net-im/skype |
| 32 |
|
| 33 |
These are the packages that would be merged, in order: |
| 34 |
|
| 35 |
Calculating dependencies... done! |
| 36 |
[ebuild R ] net-voip/skype-1.3.0.30-r1 |
| 37 |
|
| 38 |
(where net-voip/skype is copied from net-im/skype, then net-im/skpe is |
| 39 |
rewritten as an alias), which is clear and simple (it's hardly more |
| 40 |
than what emerge does if you only give it the package name). Aliases |
| 41 |
can be ignored when the category is not specified (unless we permit |
| 42 |
aliasing with different package names, which I suggest we do not). |
| 43 |
|
| 44 |
Similarly with 'emerge -s' - it would return the canonical CP. |
| 45 |
|
| 46 |
|
| 47 |
The only "mess" is that we end up with the alias data in the tree |
| 48 |
and that gradually accumulates. However it won't change once it's first |
| 49 |
setup so won't incur any significant synchronisation overhead (beyond |
| 50 |
the overhead for the actual move as done currently). I've mentioned the |
| 51 |
<CP>/alias idea elsewhere, however that's not the only way to do it - |
| 52 |
one simple method could be to have a simple text file (e.g. |
| 53 |
${PORTDIR}/profiles/alias) listing all the aliases. That's no mess at |
| 54 |
all: |
| 55 |
|
| 56 |
---- example alias file contents |
| 57 |
# Alias category/package Resident category |
| 58 |
net-im/skype net-voip |
| 59 |
---- |
| 60 |
|
| 61 |
-- |
| 62 |
Kevin F. Quinn |
Archives