On Tue, May 10, 2005 at 10:59:42PM -0700, Duncan wrote: > > 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.
Yeah, it's usually something I hit everytime I build a new box- it is valid though, and I think it makes sense. app-vim/sudo makes sense in the context of the category, just the same as app-admin/sudo does. While frustrating, I still posit it's not a huge problem. The actual number of conflicts I haven't looked up, but I would expect it's not huge in comparison to the # of packages we have. > 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? Binpkgs implementation sucks. The current "slap em all in a dir and abuse symlinks" bit can be dodged down the line. > 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? Umm. yes? Cleanup of stuff in general is in the works, including (done when it's done) binpkg handling being tweaked, which may or may not cover the huge-ass block of requests above :) > 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? Source works, not sure when it was added, but it's not source in the sense of bash's source; it just makes the make.conf interpretter/parser (it's not bash based) go and read whatever it's pointed at. 2.0.51.19 has it at least, possibly earlier. '.' however doesn't fly, from what I can see source wise at least. ~brian -- gentoo-dev@gentoo.org mailing list
