On Fri, Jul 21, 2006 at 08:44:35AM +0100, Stuart Herbert wrote: > In fact, categories do not give us the complete ability to have two > packages with the same upstream name in the tree ... because binary > packages do not support category names at all.
BZZZZZZZZ. They do actually- the bintree *repository* format flattens the namespace, thus screwing the ability to use category as part of the key for lookup. That said, the binpkgs themselves still carry their original category. Fixing the namespace flattening is easy for bintrees- problem is it'll screw over remote binhost implementation, which relies on remote listdir (essentially) of the All directory to figure out what's available. Personally I'd be inclined to give existing remote bintree implementation the boot (ugly code, slow due to it's design), but others will bitch. > >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? 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. ~harring
pgpTR3jYhLxtZ.pgp
Description: PGP signature
