From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10942 invoked by uid 1002); 25 Apr 2003 19:53:15 -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 7631 invoked from network); 25 Apr 2003 19:53:15 -0000 Date: Fri, 25 Apr 2003 21:57:15 +0200 From: kikov@fco-gimeno.com To: Joshua Brindle Cc: gentoo-dev@gentoo.org Message-ID: <20030425195715.GA10001@fco-gimeno.com> References: <20030425T113433Z_B95E00150000@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030425T113433Z_B95E00150000@gentoo.org> User-Agent: Mutt/1.5.3i Subject: Re: [gentoo-dev] Several portage trees X-Archives-Salt: 21ad77da-bae2-4932-9e93-cc23ea50766b X-Archives-Hash: 694982d378ca815eff7eb3fc1c9b97d4 > >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 ehh..... well, it's not irrelevant, IMHO. Debian has good things and bad things... I think that Gentoo is reaching the top of his development model. We have seen this on thi delaying of recent packages. Seemant is setting up the new development model. Maybe, what I'm saying it's an idea about it. > >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, Well... I'm a developer of a project. I have submitted via bugzilla several bugs of one of the packages I need ( not from the project, just a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333 ohh, yeah, 2002-05-02 07:28 EST... One year ago... The bug is still opened. I have come back to the new versions of the software... In a completely new system, and the ebuild works fine. So, I need to make 1 dependency package, and 6 for the rest of the project. I don't want to wait 6 years ( 1 -> 1 year, 2 -> 2 years, and so... ) to get my ebuilds in. The way: make an ebuild repository... The problem: deploy them easily Yes, I know that I can make a .tar.gz of my port_overlay... But users have to do: 1) Localize URL of the tar.gz 2) Download it 3) Move it to /usr/local 4) Untar it 5) emerge them When using the portage mirror, just 1) Add the portage mirror to the list 2) emerge rsync 3) emerge them > 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. The support should be of the project development team. > 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. ouch... This is the problem. > > 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 I hope it BR. Thx -- gentoo-dev@gentoo.org mailing list