Re: [gentoo-dev] Several portage trees

> >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@g.o mailing list