Subject: Re: Several portage trees
Newsgroups: gmane.linux.gentoo.devel
Date: 2003-04-25 16:34:00 GMT (5 years, 24 weeks, 4 days, 9 hours and 38 minutes ago)
>I was wondering about having several portage trees to allow external >distributor having repositories of packages. >Recently, people have been talking in this list about the difficult proccess >of making a deploy of their packages. 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 >installed to the system in a clear way. Just by putting deb lines into the >sources.list. irrelavent >Now the portage have the possibility of using a different portage from >PORTDIR_OVERLAY. >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 (nuke your metadata and try an emerge -ep world or emerge -s and you'll see what i mean). Having separate trees pretty much disallows using server side metadata in this way since the metadata wouldn't show inter-tree dependancies. >In make.conf >------ >PORT_SOURCES="rsync://source1 rsync://source2" ( it also could be useful if >ftp:// is allowed to ( mirror command ) because setup an ftp server is much >easier than a rsync one for several reasons like permissions ;) ) > >PORT_SOURCES_DIR=/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.. >So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several >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, 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, especially if you are using third party libraries to link against, etc. 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. 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). 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 handle distribution manually. Summary: I agree with the need for these but it certainly isn't 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 <at> gentoo.org mailing list