1 |
On Wed, Aug 17, 2011 at 11:56 AM, Alex Alexander <wired@g.o> wrote: |
2 |
> On Wed, Aug 17, 2011 at 19:45, Thomas Kahle <tomka@g.o> wrote: |
3 |
>> Hi, |
4 |
>> |
5 |
>> I'm forking from a thread on gentoo-project: |
6 |
>> |
7 |
>> On 17:26 Wed 17 Aug 2011, Markos Chandras wrote: |
8 |
>>> Personally, I want to shrink portage. There is no way for 250 listed |
9 |
>>> developers ( I would be glad if 100 of us were really active ) to |
10 |
>>> maintain thousands of ebuilds. |
11 |
>> [...] |
12 |
>>> We need to support only the packages that we can *really* support and |
13 |
>>> lets hope that more people will join in when they see their packages |
14 |
>>> going away. |
15 |
>> |
16 |
>> I like the idea of shrinking portage, but here's a scenario I'd like to |
17 |
>> avoid: |
18 |
>> |
19 |
>> 1) package A is unmainted, but has a sophistacted ebuild that evolved |
20 |
>> over some time. |
21 |
>> |
22 |
>> 2) A has an open bug that nobody cares to fix, treecleaners come around |
23 |
>> and remove A. |
24 |
>> |
25 |
>> 3) New dev X joines Gentoo and cares for A and startes to rewrite the |
26 |
>> ebuild from scratch. |
27 |
>> |
28 |
>> Is there a way for X to easily query the portage history and dig up the |
29 |
>> ebuild that was there at some point. She could then use the old ebuild |
30 |
>> for their new version, but without efficient search she would probably |
31 |
>> start from scratch. Some packages are treecleaned in the state 'working |
32 |
>> but with a single bug (and nobody cares)', it would be good if that |
33 |
>> state is somehow retained after the removal. Then you can get a fully |
34 |
>> working package while fixing only one bug. |
35 |
>> |
36 |
>> Searching through mailing list archives with automatted removal mails |
37 |
>> would be my hack, what would be yours? |
38 |
>> |
39 |
>> Cheers, |
40 |
>> Thomas |
41 |
> |
42 |
> We could try removing all keywords and masking ebuilds that are |
43 |
> abandoned with bugs but upstream is still active, instead of removing |
44 |
> them completely. That way the ebuild will be there when/if someone |
45 |
> else decides to take care of the package and it will even show in |
46 |
> tools like eix. |
47 |
> |
48 |
> -- |
49 |
> Alex Alexander | wired |
50 |
> + Gentoo Linux Developer |
51 |
> ++ www.linuxized.com |
52 |
> |
53 |
> |
54 |
|
55 |
+1 on this. It saves the ebuild for posterity AND prevents users |
56 |
hitting nasty bits. This seems to me to beg for a proper well-defined |
57 |
policy, in any case. |
58 |
|
59 |
-- |
60 |
Matthew W. Summers |
61 |
Gentoo Foundation Inc. |