On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
