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 <[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.
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
pgpAtePs43wy7.pgp
Description: PGP signature
