| 1 |
>> >As we know, Debian uses this. Everyone can add a new source of packages to get |
| 2 |
>> >installed to the system in a clear way. Just by putting deb lines into the |
| 3 |
>> >sources.list. |
| 4 |
>> |
| 5 |
>> irrelavent |
| 6 |
>ehh..... well, it's not irrelevant, IMHO. Debian has good things and bad |
| 7 |
>things... |
| 8 |
>I think that Gentoo is reaching the top of his development model. We |
| 9 |
>have seen this on thi delaying of recent packages. |
| 10 |
> |
| 11 |
>Seemant is setting up the new development model. Maybe, what I'm saying |
| 12 |
>it's an idea about it. |
| 13 |
|
| 14 |
Wow, i haven't heard about this, you must be more informed than us developers |
| 15 |
|
| 16 |
>> >So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several |
| 17 |
>> >trees allowed ). |
| 18 |
>> > |
| 19 |
>> >Is this too hard to implement? |
| 20 |
>> > |
| 21 |
>> >I think it solves a lot of complains about flexibility and edging of Gentoo. |
| 22 |
>> |
| 23 |
>> this isn't a flexibility issue, it's trivial to download ebuilds and use them, |
| 24 |
>> write your own, distribute them, maintain your own portdir_overlay |
| 25 |
>> etc, there are inherent problems, especially with bugtracking, third |
| 26 |
>> party ebuilds can cause problems in other gentoo proper ebuilds, |
| 27 |
>Well... I'm a developer of a project. I have submitted via bugzilla |
| 28 |
>several bugs of one of the packages I need ( not from the project, just |
| 29 |
>a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333 |
| 30 |
>ohh, yeah, 2002-05-02 07:28 EST... One year ago... |
| 31 |
>The bug is still opened. |
| 32 |
> |
| 33 |
>I have come back to the new versions of the software... In a completely |
| 34 |
>new system, and the ebuild works fine. |
| 35 |
> |
| 36 |
> |
| 37 |
>So, I need to make 1 dependency package, and 6 for the rest of the |
| 38 |
>project. I don't want to wait 6 years ( 1 -> 1 year, 2 -> 2 years, and |
| 39 |
>so... ) to get my ebuilds in. |
| 40 |
> |
| 41 |
>The way: make an ebuild repository... |
| 42 |
>The problem: deploy them easily |
| 43 |
> |
| 44 |
>Yes, I know that I can make a .tar.gz of my port_overlay... But users |
| 45 |
>have to do: |
| 46 |
>1) Localize URL of the tar.gz |
| 47 |
>2) Download it |
| 48 |
>3) Move it to /usr/local |
| 49 |
>4) Untar it |
| 50 |
>5) emerge them |
| 51 |
>When using the portage mirror, just |
| 52 |
>1) Add the portage mirror to the list |
| 53 |
>2) emerge rsync |
| 54 |
>3) emerge them |
| 55 |
> |
| 56 |
>> Also say someone write an ebuild (for example oracle, and distributes |
| 57 |
>> if in his own tree), this extra ebuild has essentially done nothing |
| 58 |
>> for the system or the user. Countless other ebuilds would have to be |
| 59 |
>> edited to add support for oracle, patches if required, conf flags, etc. |
| 60 |
>> the user would end up having to maintain lots of duplicate ebuilds |
| 61 |
>> in his tree, and run the risk of his getting out of date and a user updating |
| 62 |
>> with newer gentoo ebuilds (which dont' have oracle support). |
| 63 |
>> This situation doesn't help anyone.. adding the ebuilds into the main |
| 64 |
>> gentoo tree and adding support to ebuilds there is an optimal solution. |
| 65 |
>The support should be of the project development team. |
| 66 |
|
| 67 |
you aren't even listening |
| 68 |
the problem is that it isn't easy to know what causes the bug, and i can |
| 69 |
see countless hours being spent by Gentoo devs tracking down a bug that |
| 70 |
they find out later is caused by an unrelated ebuild in a 3rd party tree, |
| 71 |
don't tell me it won't happen, I know better. |
| 72 |
|
| 73 |
_Additionally_ you didn't answer my concern about whoever running |
| 74 |
the repository having to keep their stuff up to date and in line with |
| 75 |
gentoo proper, it's extra work for him, it's extra risk for his users, |
| 76 |
all around it isn't a clean solution. |
| 77 |
|
| 78 |
>> On the other hand their are no doubt companies which will want |
| 79 |
>> to keep proprietary products/ebuilds for themselves, and they can |
| 80 |
>> with the current PORTDIR_OVERLAY system, but portage won't |
| 81 |
>> handle distribution manually. |
| 82 |
>ouch... This is the problem. |
| 83 |
|
| 84 |
no, you want to distribute your apps use cvs or rsync outside |
| 85 |
of portage, it's simple, you could even cron it, most of us devs |
| 86 |
don't keep our local repository up to date with portage, we simply |
| 87 |
use cvs up |
| 88 |
|
| 89 |
>> |
| 90 |
>> Summary: I agree with the need for these but it certainly isn't |
| 91 |
>> as simple as you apparently believe. I think portage will probably |
| 92 |
>> go in this direction but don't count on it pre portage 2.1 |
| 93 |
>I hope it |
| 94 |
> |
| 95 |
probably not until the problems i've said here are addressed. |
| 96 |
noone likes getting bugs, and noone really likes getting bugs |
| 97 |
caused by 3rd party apps |
| 98 |
|
| 99 |
You also didn't mention the problems i addressed wrt metadata |
| 100 |
and caches. This isn't going to happen until those problems |
| 101 |
are solved. |
| 102 |
|
| 103 |
-- |
| 104 |
gentoo-dev@g.o mailing list |
Archives