Re: [gentoo-dev] New category: net-voip

[Brian Harring]

On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote:
> On Fri, 21 Jul 2006 01:05:20 -0700
> Brian Harring <ferringb@×××××.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.

A disadvantage being that without a tree, your graph is broken 
(aliases live in the tree); this includes using strictly a bintree 
(remote or otherwise).

Big disadvantage, hence why that approach was ignored last time it was 
brought up.
~harring