Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Brian Harring]

On Mon, May 02, 2005 at 09:11:03PM -0500, Brian Jackson wrote:
> Well, I've got a bug open to have a different variable like ROOT that
> portage would read config files from. Maybe you could jump on that
> bandwagon, and see if you can make things work that way.

Assuming you're referencing CONFIG_ROOT, it frankly isn't much of a 
solution for his needs.  The problem with CONFIG_ROOT is you would 
have to set it for every emerge invocation.  His intention is to have 
portage function from a variable prefix, and install to a build time 
defined prefix.  IOW, portage using different paths on an installed 
box, not portage installed to it's normal location, and hacked up via 
an environment variable to try and change the behaviour.

I'm not much for config_root, obviously.  The intention of it, and 
varying root (imo) is a hack around portage's expectations about it's 
configuration and repos.  It's not much of a proper solution.


> I just don't see the uptake to fix a very large portion of the tree for
> something that I'd guess most devs think is pointless.

Aparently people didn't notice the multilib changes passing through 
the tree the last few months?  Same type of wide spread change, yet 
it's being done, and ebuilds are being migrated.  Things break, but 
the party/person interested in adding the support is doing the work.

Sidenote re: fixing a large portion of the tree, eclasses and 
portage's base template for ebuilds would be the first start in 
terms of changes.  That 'very large' portion of the tree arguement 
would be ixnayed via that, what would remain is a collection of 
pissy packages that need manual tweaking.


> That's also the
> reason the "enterprise" tree hasn't taken off.
> People working in their free time couldn't give a crap about people
> thinking Gentoo isn't suitable for enterprise applications.

The reason for the enterprise tree not being ready/finished, or even 
*accepted* (it _still_ is a draft after all) is frankly no ones fault 
but those who want such a tree.  The reason glep25 (my own glep) isn't 
implemented is again, no ones fault but those pushing it (read: me).  
Might want to clarify what you're asserting, cause I'm not seeing the 
validity in it...

So... yeah, the enterprise angle imo is slightly daft.  If you're 
arguing that their are more 'important' things to do rather then this, 
state it as such, or please clarify...


> If you want to use portage, use Gentoo.

That should be "or put in the grunt work to support it".  If I recall 
correctly, you're working on gentoo embedded.  The arguements you're 
leveling above could just as easily be used against expanding the tree 
to support uclibc, or a slightly saner example, dropping osx support 
(portage _is_ the secondary manager there).  Hell, y'all are in a 
similar boat, for actual device updating you'll be using emerge.c, 
which _isn't_ portage, just compatible with the binpkg support.  

Either way, my point is that portage/gentoo will flow into the niche's 
people care to expand it into.  It's pointless telling them not to do 
it, because they _will_ do it anyways if it makes sense to them.  So 
point out the failings, or better solutions.

Yeah, time for me to step down from the soapbox I think...

> If you want some package manager
> for your solaris/x86 box(just an example!), go talk to the people that
> do openembedded.

Clarify why portage, which _does_ function as a secondary pkg manager 
(collision-protect wouldn't exist otherwise) wouldn't suffice if 
someone gave enough of a damn to do the work?

So yeah, anyone care to comment about the proposal's specifics, rather 
then "piss off, no..." ?  :)
~brian