On Wed, May 11, 2005 at 07:09:20, Brian Harring wrote: > One thing that just clicked in the skull on why flat-tree has issues; > > currently it's possible to have a package with the same name, yet a > differing category (app-vim/sudo vs app-admin/sudo).
Aa flat package namespace would necessitate renaming any existing package name clashes. The essential problem with categories is that you will always have confusion in some cases as to which category a package should be in; it's natural that some packages will make sense in more than one category. A good example of this problem with categories can be seen in the CDDB/FreeDB track listing database which does a similar category thing with category/album-hash (the problem is pretty acute there, not least because the probability of clashes in the album-hash is high, but also because people disagree whether their favourite album is new-age, folk, etc). Here's my suggestion, for what it's worth :) The layout on disk and the semantics of categories do not need to be related. I like the idea of using the first character of a package name as the sub-directory name. This can be extended more deeply as and when necessary to avoid over-large directories which cause problems on some filesystems. e.g. for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is architecture-neutral, rsyncable, scalable, and not too difficult for users to parse manually (see later for searching through categories). If the algorithm portage would use to locate a package is such that it doesn't mandate the depth (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" exists) then overlays can have a different depth to the rsync tree; if you only have a few packages in overlay then they need not be in subdirectories at all. The key here is to separate the category (metadata) and filesystem layout (implementation detail) from the concept of package name. This opens up all sorts of possibilities, for example different layouts in CVS, on mirrors and on clients (some kind of custom rsync would be necessary) - but that's going perhaps too far... Categories become metadata, formally (this is the root of the problem - including the category in the package name is a pollution of the package name). Once they become properly understood and implemented as metadata, a package being a member of more than one category is a natural consequence. Whether category should be in the ebuild or in metadata.xml is a another issue. We already have some metadata in the ebuilds (e.g. DESCRIPTION). However that's really a separate debate; the question of whether all metadata that isn't version-dependent and doesn't impact the emerge process should be moved from ebuilds to metadata.xml... Portage would essentially ignore categories. Some support would be necessary to allow the user to query categories (since 'ls /usr/portage/<category>' would no longer work) - but searching for packages is already a function and would just need to be adapted (and perhaps optimised ;) ). Indeed just listing out portage directories at the moment is often insufficient to find a suitable package, since package names are often amusing but uninformative acronyms. The real problem with implementing the above is the amount of work it would take to modify portage and the tree, for relatively little gain at the moment. I'm certainly not volunteering :) The benefits include 1) no more "moving packages around the tree" 2) categories can be added to a package in the most natural way 3) overlays can be tidier The downsides include 1) Massive upheaval in the portage tree 2) Massive upheaval in the portage tree 3) Massive upheaval in the portage tree well, it's a big downside... Having said that, some things could be done now. If a flat package namespace is desirable, the existing package name clashes could be resolved by renaming the few packages that clash. Category could be added as a field in metadata.xml, so that a package could "belong" to multiple categories. The query/search tools could be enhanced to scan this metadata (perhaps including the current category directory as an implied entry in the metadata.xml). Kev. -- gentoo-dev@gentoo.org mailing list
