On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:

> Kevin F. Quinn wrote:
> > An advantage to this approach is that package moves just become
> > aliases
> > - existing stuff doesn't break yet you get the new categorisation as
> > well.
> 
> That's actually a disadvantage.  The whole point of moving a package
> is to take it *out* of its existing category.

No, the point is to take it from a category where it's membership is
not so strong, to one where it is stronger.  For exmaple, it's not that
net-im is the wrong place for skype, it's just that net-voip is in some
ways better.  Where categorisation is clearly very wrong then it should
be moved as soon as possible (for example if skype had initially been
placed in www-apps) but that's an initial commit problem rather than
maintenance going forward.

>  Just adding an alias
> into a second category makes the tree more of a mess - not less.

The alias, once setup, can be left alone forever.  As far as any
further maintenance is concerned, it requires none.  Even if the
package is moved again, the alias can still point to the second
location which becomes an alias for the final location.  As far as
users are concerned, assuming aliases are resolved when being parsed,
they would see:

  $ emerge -p net-im/skype

  These are the packages that would be merged, in order:

  Calculating dependencies... done!
  [ebuild     R ] net-voip/skype-1.3.0.30-r1

(where net-voip/skype is copied from net-im/skype, then net-im/skpe is
rewritten as an alias), which is clear and simple (it's hardly more
than what emerge does if you only give it the package name).  Aliases
can be ignored when the category is not specified (unless we permit
aliasing with different package names, which I suggest we do not).

Similarly with 'emerge -s' - it would return the canonical CP.


The only "mess" is that we end up with the alias data in the tree
and that gradually accumulates.  However it won't change once it's first
setup so won't incur any significant synchronisation overhead (beyond
the overhead for the actual move as done currently).  I've mentioned the
<CP>/alias idea elsewhere, however that's not the only way to do it -
one simple method could be to have a simple text file (e.g.
${PORTDIR}/profiles/alias) listing all the aliases.  That's no mess at
all:

---- example alias file contents
# Alias category/package   Resident category
net-im/skype               net-voip
----

-- 
Kevin F. Quinn

Attachment: signature.asc
Description: PGP signature

Reply via email to