On 26 June 2011 05:29, Ulrich Mueller <u...@gentoo.org> wrote: >>>>>> On Sat, 25 Jun 2011, Maciej Mrozowski wrote: > >> Assuming package names are unique identifiers, tags are not >> necessary to be available for ebuild.sh so metadata.xml is the best >> place. > > But we know that package names are _not_ unique. There are many cases > in the Portage tree where two or even more packages have the same > name. Categories are there to avoid such collisions. > > With multiple overlays/repositories instead of one monolithic Portage > tree, the collision issue gets even worse if you have a flat > namespace. > > Ulrich > >
At present, this exists because we use categories as a the primary way for a *user* to find the package. Our current collision avoidance strategy is targeted at not confusing our *user*. However, in the proposed strategy, package names themselves are not *users* primary interface. "tags" and other metadata are intended as the users primary interface. Package names themselves can be thusly arbitrary , and could be a SHA sum or something obscure, as long as all internals and dependencies used the same arbitrary name, things would work as intended. There is one remaining downside to the flat topology however, and that is it may hamper our move to git. I was thinking that what could be done is have seperate submodules or whathave you for various categories to somewhat ease the load of "A full checkout of the tree going back for all time can be bloody huge and slow" , but without categorical subtrees that approach will be less viable. Although, this what currently seems like a disadvantage could be used to an advantage perhaps, with the possible idea of "meta trees" of some description. If we relinquish the hold we have on symlinks, a few interesting options become available. Different Herds could have their own subtrees in /projects/herd/<x> and a tool could be used to symlink the contents of herd specific subtrees to the ebuilds folder. /ebuild/<pn> --> /projects/herd/<herdname>/<pn> And the tool can inform herds when they add a new package that conflicts with the name of an existing one so it can be disambiguated before the tree propagates to users. Continuing on that line of thought and you get even more interesting ideas, like introducing a "merge mask" file, which allows people to work on stuff in the herd tree , and indicate that their files/packages are not fit for integration with the main-tree yet, somewhat bridging the gap we presently have between "Development" overlays and the current main tree. This could in turn make collaboration even easier, as dev branches will be able to go nuts with all sorts of random contributions, and when its deemed fit for public consumption and testing remove the package from the merge mask and its there. </early morning coffee fuelled idea session> -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
