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
pgpk97ief0kMp.pgp
Description: PGP signature
