1 |
>I was wondering about having several portage trees to allow external |
2 |
>distributor having repositories of packages. |
3 |
>Recently, people have been talking in this list about the difficult proccess |
4 |
>of making a deploy of their packages. |
5 |
|
6 |
Actually I like this idea and advocated it a while back but it was shot down.. |
7 |
> |
8 |
>As we know, Debian uses this. Everyone can add a new source of packages to get |
9 |
>installed to the system in a clear way. Just by putting deb lines into the |
10 |
>sources.list. |
11 |
|
12 |
irrelavent |
13 |
|
14 |
>Now the portage have the possibility of using a different portage from |
15 |
>PORTDIR_OVERLAY. |
16 |
>It could be really useful, if we could use something like it |
17 |
|
18 |
not PORTDIR_OVERLAY per se, i think something like |
19 |
/usr/portage/gentoo |
20 |
/usr/portage/othervendor |
21 |
/usr/potage/anothervendor |
22 |
|
23 |
would do, the problem is dependancy tracking and caching. |
24 |
right now dependancy metadata is generated before rsync |
25 |
mirrors are updated, this is a tremendous benefit for users |
26 |
(nuke your metadata and try an emerge -ep world or emerge -s |
27 |
and you'll see what i mean). Having separate trees pretty much |
28 |
disallows using server side metadata in this way since the |
29 |
metadata wouldn't show inter-tree dependancies. |
30 |
|
31 |
>In make.conf |
32 |
>------ |
33 |
>PORT_SOURCES="rsync://source1 rsync://source2" ( it also could be useful if |
34 |
>ftp:// is allowed to ( mirror command ) because setup an ftp server is much |
35 |
>easier than a rsync one for several reasons like permissions ;) ) |
36 |
> |
37 |
>PORT_SOURCES_DIR=/usr/local/portages/ |
38 |
>------ |
39 |
> |
40 |
>So, after making an emerge rsync, we have: |
41 |
>/usr/portage -> with the official gentoo portage mirror |
42 |
>/usr/local/portages/source1 -> with the mirror of the source1 |
43 |
>/usr/local/portages/source2 -> with the mirror of the source2 |
44 |
>and so... |
45 |
|
46 |
yea, this might work too.. |
47 |
|
48 |
>So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several |
49 |
>trees allowed ). |
50 |
> |
51 |
>Is this too hard to implement? |
52 |
> |
53 |
>I think it solves a lot of complains about flexibility and edging of Gentoo. |
54 |
> |
55 |
|
56 |
this isn't a flexibility issue, it's trivial to download ebuilds and use them, |
57 |
write your own, distribute them, maintain your own portdir_overlay |
58 |
etc, there are inherent problems, especially with bugtracking, third |
59 |
party ebuilds can cause problems in other gentoo proper ebuilds, |
60 |
especially if you are using third party libraries to link against, etc. |
61 |
Also say someone write an ebuild (for example oracle, and distributes |
62 |
if in his own tree), this extra ebuild has essentially done nothing |
63 |
for the system or the user. Countless other ebuilds would have to be |
64 |
edited to add support for oracle, patches if required, conf flags, etc. |
65 |
the user would end up having to maintain lots of duplicate ebuilds |
66 |
in his tree, and run the risk of his getting out of date and a user updating |
67 |
with newer gentoo ebuilds (which dont' have oracle support). |
68 |
This situation doesn't help anyone.. adding the ebuilds into the main |
69 |
gentoo tree and adding support to ebuilds there is an optimal solution. |
70 |
|
71 |
|
72 |
On the other hand their are no doubt companies which will want |
73 |
to keep proprietary products/ebuilds for themselves, and they can |
74 |
with the current PORTDIR_OVERLAY system, but portage won't |
75 |
handle distribution manually. |
76 |
|
77 |
Summary: I agree with the need for these but it certainly isn't |
78 |
as simple as you apparently believe. I think portage will probably |
79 |
go in this direction but don't count on it pre portage 2.1 |
80 |
|
81 |
Joshua Brindle |
82 |
|
83 |
-- |
84 |
gentoo-dev@g.o mailing list |