On Sat, 22 Jul 2006 21:42:07 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn" > <[EMAIL PROTECTED]> wrote: > | 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. > > Not that simple. Think about installed packages, overlays and changing > aliases. The package manager would need to keep track of what aliases > were at any given time. Not if the aliases are resolved to the canonical CP when they are parsed. At any point in time, the dep resolver would be working with canonical CPs as they exist at that point, not what they were when the package was installed or the binpackage was built. > Then there're symlinks to outside the tree and Maybe I've misunderstood you here, but surely aliasing from inside the tree to outside it (e.g. to an overlay package not present in the primary tree) would not be sensible. > circular symlinks... There's a lot more too it than is initially > obvious. My understanding is that circular dependencies are not supported; the situation would be no different with aliasing, pretty much by definition if nothing else - all aliases should ultimately resolve to a real package, which they can't do if you allow circular aliases. > | 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. > > Files are cleaner than symlinks for other reasons too. Also allows the > opportunity of making 'deprecated' aliases that issue QA warnings. > > | > 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. > > Perhaps you should think. It's nowhere near as straight forward as you > claim. Which is not to say it's not doable, just that it's not doable > cheaply... I still don't see how, if aliases are canonicalised when they are parsed, the issue becomes more complex. Internally the package manager would always think in terms of the canonical CP, at which point it's not doing anything that it isn't already. -- Kevin F. Quinn
signature.asc
Description: PGP signature
