Re: [gentoo-dev] Re: Re: New category proposal

[Brian Harring]

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@g.o mailing list