On Fri, 21 Jul 2006 01:05:20 -0700
Brian Harring <ferringb@gmail.com> wrote:

> > >Unfortunately the category system is deeply embedded in portage
> > >and the tree, so changing that system is simply not going to
> > >happen, which is why I've stopped whinging about the semantic
> > >inadequacy of the system.
> > 
> > Instead of whinging about why the existing categories are bad, why
> > not instead put forward an alternative (preferably with code, but a
> > clear and consistently argued position would be a start) for
> > something better?  Otherwise, you *are* going to be ignored ... and
> > with good reason.
> 
> Just so we're clear, I probably will wedgie anyone who suggests
> trying to extend the existing tree format with N categories per pkg-
> sounds nice on paper, but it makes lookup a serious pita-
> sys-apps/portage, we'll pretend it's actually located in sys-apps,
> and it's also in category 'pkg-managers'.  An atom states
> 'pkg-managers/portage'; how does a pkg manager do a lookup for it?

Since the names would be aliased, either reference would be fine i.e. a
dep on pkg-managers/portage would be equivalent to sys-apps/portage.

If it were to be implemented with symlinks (implying one entry is "real"
and the others are aliases) the package manager just needs to
canonicalise any symlinked CPs it comes across.

Since we can't have symlinks in CVS, there are other ways it can be
done; first thing that pops into my head is an "alias" package entry in
the tree, where instead of ebuilds & files/ etc it would just contain a
file "alias" with the category (and perhaps package name) of the aliased
package.

I would expect it to be non-trivial to implement in portage, since
portage code has evolved for so long assuming that a package is in one
category - I'm not saying portage code is bad, I'm just saying that
much of it may have been implemented under that assumption and breaking
it means testing lots of stuff.

> Has to walk the entire tree... so if N category per pkg is going to
> be proposed, need to preserve the fast lookup that's there now.

I don't think the above ideas cause any substantial change to the
amount of processing required.

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.

-- 
Kevin F. Quinn