On Sat, 22 Jul 2006 13:35:08 -0700 Brian Harring <[EMAIL PROTECTED]> wrote:
> 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). I don't get what you're talking about here; perhaps I'm missing something. I don't see why the deps can't be managed by canonicalising every reference as they are parsed. As you build the graph, the aliases disappear as they are canonicalised before they reach the graph. That way the only place aliases exist is in the portage tree itself - the package manager can forget about them once it has parsed the deps. Certainly trying to build the dependency tree without canonicalising aliases would be a mess; anyone trying to do it like that is asking for trouble. You want unique names for everything for which you're building the dependency tree. > Big disadvantage, hence why that approach was ignored last time it > was brought up. -- Kevin F. Quinn
signature.asc
Description: PGP signature
