From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j432lkfq005932 for ; Tue, 3 May 2005 02:47:46 GMT Received: from adsl-67-39-48-193.dsl.milwwi.ameritech.net ([67.39.48.193] helo=exodus) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DSnRr-0004YQ-Pv for gentoo-dev@lists.gentoo.org; Tue, 03 May 2005 02:47:47 +0000 Date: Mon, 2 May 2005 21:48:10 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] new glep draft: Portage as a secondary package manager Message-ID: <20050503024810.GB10998@exodus.wit.org> References: <42761B77.4030206@salomon.at> <42767C63.40400@gentoo.org> <4276CCC5.1080602@egr.msu.edu> <1115086263.24870.7.camel@matrix.brianandsara.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <1115086263.24870.7.camel@matrix.brianandsara.net> User-Agent: Mutt/1.5.8i X-Archives-Salt: 4426d3bb-e39d-4302-9956-8945103890c0 X-Archives-Hash: 1b0f929d3318cbdcb5891e4320e0e03c --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 solution for his needs. The problem with CONFIG_ROOT is you would=20 have to set it for every emerge invocation. His intention is to have=20 portage function from a variable prefix, and install to a build time=20 defined prefix. IOW, portage using different paths on an installed=20 box, not portage installed to it's normal location, and hacked up via=20 an environment variable to try and change the behaviour. I'm not much for config_root, obviously. The intention of it, and=20 varying root (imo) is a hack around portage's expectations about it's=20 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.=20 Aparently people didn't notice the multilib changes passing through=20 the tree the last few months? Same type of wide spread change, yet=20 it's being done, and ebuilds are being migrated. Things break, but=20 the party/person interested in adding the support is doing the work. Sidenote re: fixing a large portion of the tree, eclasses and=20 portage's base template for ebuilds would be the first start in=20 terms of changes. That 'very large' portion of the tree arguement=20 would be ixnayed via that, what would remain is a collection of=20 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=20 *accepted* (it _still_ is a draft after all) is frankly no ones fault=20 but those who want such a tree. The reason glep25 (my own glep) isn't=20 implemented is again, no ones fault but those pushing it (read: me). =20 Might want to clarify what you're asserting, cause I'm not seeing the=20 validity in it... So... yeah, the enterprise angle imo is slightly daft. If you're=20 arguing that their are more 'important' things to do rather then this,=20 state it as such, or please clarify... > If you want to use portage, use Gentoo.=20 That should be "or put in the grunt work to support it". If I recall=20 correctly, you're working on gentoo embedded. The arguements you're=20 leveling above could just as easily be used against expanding the tree=20 to support uclibc, or a slightly saner example, dropping osx support=20 (portage _is_ the secondary manager there). Hell, y'all are in a=20 similar boat, for actual device updating you'll be using emerge.c,=20 which _isn't_ portage, just compatible with the binpkg support. =20 Either way, my point is that portage/gentoo will flow into the niche's=20 people care to expand it into. It's pointless telling them not to do=20 it, because they _will_ do it anyways if it makes sense to them. So=20 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=20 (collision-protect wouldn't exist otherwise) wouldn't suffice if=20 someone gave enough of a damn to do the work? So yeah, anyone care to comment about the proposal's specifics, rather=20 then "piss off, no..." ? :) ~brian --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCduZqvdBxRoA3VU0RAhEjAKCLVC15VmQ2eRvlgyAX+uZivsH+VwCglyQj pcgJSETndyE/XoY8JSO5HBY= =JxX1 -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- -- gentoo-dev@gentoo.org mailing list