From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21828 invoked by uid 1002); 25 Apr 2003 16:38:47 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 8108 invoked from network); 25 Apr 2003 16:38:46 -0000 Mime-Version: 1.0 Date: Fri, 25 Apr 2003 11:34:00 -0500 X-Mailer: Groupwise 6.0.1 Message-ID: <20030425T113433Z_B95E00150000@gentoo.org> Reply-To: method@gentoo.org From: Joshua Brindle To: gentoo-dev@gentoo.org, "Gimeno, Francisco" Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1996Dl-0002Bf-00*0PxDZR5Dsi2* Subject: Re: [gentoo-dev] Several portage trees X-Archives-Salt: 3581781e-923b-43a6-b8f8-b7fb21f016eb X-Archives-Hash: 791fffb934a42dc9d3b38f572dd54af5 >I was wondering about having several portage trees to allow external=20 >distributor having repositories of packages. >Recently, people have been talking in this list about the difficult = proccess=20 >of making a deploy of their packages.=20 Actually I like this idea and advocated it a while back but it was shot = down.. > >As we know, Debian uses this. Everyone can add a new source of packages = to get=20 >installed to the system in a clear way. Just by putting deb lines into = the=20 >sources.list. irrelavent >Now the portage have the possibility of using a different portage from=20 >PORTDIR_OVERLAY.=20 >It could be really useful, if we could use something like it not PORTDIR_OVERLAY per se, i think something like /usr/portage/gentoo /usr/portage/othervendor /usr/potage/anothervendor would do, the problem is dependancy tracking and caching. right now dependancy metadata is generated before rsync mirrors are updated, this is a tremendous benefit for users=20 (nuke your metadata and try an emerge -ep world or emerge -s=20 and you'll see what i mean). Having separate trees pretty much=20 disallows using server side metadata in this way since the=20 metadata wouldn't show inter-tree dependancies. >In make.conf >------ >PORT_SOURCES=3D"rsync://source1 rsync://source2" ( it also could be = useful if=20 >ftp:// is allowed to ( mirror command ) because setup an ftp server is = much=20 >easier than a rsync one for several reasons like permissions ;) ) > >PORT_SOURCES_DIR=3D/usr/local/portages/ >------ > >So, after making an emerge rsync, we have: >/usr/portage -> with the official gentoo portage mirror >/usr/local/portages/source1 -> with the mirror of the source1 >/usr/local/portages/source2 -> with the mirror of the source2 >and so... yea, this might work too..=20 >So, when implementing, it could be used as the PORTDIR_OVERLAY ( with = several=20 >trees allowed ). > >Is this too hard to implement? > >I think it solves a lot of complains about flexibility and edging of = Gentoo. > this isn't a flexibility issue, it's trivial to download ebuilds and use = them,=20 write your own, distribute them, maintain your own portdir_overlay etc, there are inherent problems, especially with bugtracking, third party ebuilds can cause problems in other gentoo proper ebuilds,=20 especially if you are using third party libraries to link against, etc.=20 Also say someone write an ebuild (for example oracle, and distributes if in his own tree), this extra ebuild has essentially done nothing for the system or the user. Countless other ebuilds would have to be edited to add support for oracle, patches if required, conf flags, etc.=20 the user would end up having to maintain lots of duplicate ebuilds in his tree, and run the risk of his getting out of date and a user = updating with newer gentoo ebuilds (which dont' have oracle support).=20 This situation doesn't help anyone.. adding the ebuilds into the main gentoo tree and adding support to ebuilds there is an optimal solution. On the other hand their are no doubt companies which will want to keep proprietary products/ebuilds for themselves, and they can with the current PORTDIR_OVERLAY system, but portage won't=20 handle distribution manually.=20 Summary: I agree with the need for these but it certainly isn't=20 as simple as you apparently believe. I think portage will probably go in this direction but don't count on it pre portage 2.1 Joshua Brindle -- gentoo-dev@gentoo.org mailing list