Brian Harring posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 11 May 2005 00:09:20 -0500:
> 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). > > Since our tree layout is based upon category, if you tried shifting the > focus of it to packages_in anyway_, you would explicitly disallow same > name packages, different category. Doesn't matter how you structure the > tree, if you do lookup into the tree based on package, not category, you > disallow same named packages. While I'm not a flat tree supporter per se, duplicate packages are IMO a bad thing in any case, for two reasons. 1) Human. It's frustrating to do emerge sudo and have it tell you to specify, when there's only /one/ "normal" sudo. The /other/ sudo should be vim-sudo or whatever, as you mention later. 2) Bin-pkgs. As currently structured, we have a de-facto "flat" bin-pkgs layout anyway, since the tree is simply a bunch of symlinks pointing to the $PKGDIR/All dir that /all/ the packages land in. Clashing packages is NOT a good thing, as I'm sure you are aware. /Something/ really needs to be done about this one. Any possible light at the end of the tunnel here? BTW, it'd be very handy to have "slotted" bin-pkgs as well, "slotted" as in allowing me to do things like test a gcc4 created package, without erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and without having to remember to manually copy/move the existing bin-pkg first to keep that backup. A feature to enable some arbitrary identifier in the binpkg name, or an arbitrary string as a binpkg subdir path fragment, would be very helpful. Something like FEATURES=binpkg-name then enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree, or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate symlink. One could then just remember to change the $BINPKG-NAME entry in make.conf whenever one runs gcc-config, or whenever one triggers whatever switch and desires a corresponding binpkg-slot change. Anything like this in the works? Should I file an enhancement bug? Maybe the ability is there already and I just don't know it, as with the very cool make.conf "source" feature I saw mentioned on the amd64 list? BTW2, does the "." shortcut work in make.conf? I can envision a make.conf that's simply a half dozen or so lines of "source /etc/portage/make.network.conf", ". /etc/portage/make.useflags.conf", etc. Is that documented anywhere, yet? When (version) was it introduced? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
