1 |
Hi, |
2 |
|
3 |
I'm forking from a thread on gentoo-project: |
4 |
|
5 |
On 17:26 Wed 17 Aug 2011, Markos Chandras wrote: |
6 |
> Personally, I want to shrink portage. There is no way for 250 listed |
7 |
> developers ( I would be glad if 100 of us were really active ) to |
8 |
> maintain thousands of ebuilds. |
9 |
[...] |
10 |
> We need to support only the packages that we can *really* support and |
11 |
> lets hope that more people will join in when they see their packages |
12 |
> going away. |
13 |
|
14 |
I like the idea of shrinking portage, but here's a scenario I'd like to |
15 |
avoid: |
16 |
|
17 |
1) package A is unmainted, but has a sophistacted ebuild that evolved |
18 |
over some time. |
19 |
|
20 |
2) A has an open bug that nobody cares to fix, treecleaners come around |
21 |
and remove A. |
22 |
|
23 |
3) New dev X joines Gentoo and cares for A and startes to rewrite the |
24 |
ebuild from scratch. |
25 |
|
26 |
Is there a way for X to easily query the portage history and dig up the |
27 |
ebuild that was there at some point. She could then use the old ebuild |
28 |
for their new version, but without efficient search she would probably |
29 |
start from scratch. Some packages are treecleaned in the state 'working |
30 |
but with a single bug (and nobody cares)', it would be good if that |
31 |
state is somehow retained after the removal. Then you can get a fully |
32 |
working package while fixing only one bug. |
33 |
|
34 |
Searching through mailing list archives with automatted removal mails |
35 |
would be my hack, what would be yours? |
36 |
|
37 |
Cheers, |
38 |
Thomas |
39 |
|
40 |
|
41 |
-- |
42 |
Thomas Kahle |
43 |
http://dev.gentoo.org/~tomka/ |