1 |
Jorge Manuel B. S. Vicetto wrote: |
2 |
> Petteri Räty wrote: |
3 |
>> Jorge Manuel B. S. Vicetto wrote: |
4 |
>>> Hi. |
5 |
>>> |
6 |
>>> As the KDE team prepares to add revised eclasses for the KDE3 ebuilds so |
7 |
>>> we can get 3.5.10 marked stable and then finally ask for KDE4 |
8 |
>>> stabilization, we'd like to drop some old eclasses from the tree. We |
9 |
>>> plan to drop the kde-base, kde-dist, kde-i18n and kde-source eclasses as |
10 |
>>> they're no longer used. |
11 |
>>> So unless someone has any objections, we'll drop the eclasses from the |
12 |
>>> tree in the next few days. |
13 |
>>> |
14 |
>>> In case anyone has any doubts about portage reliance on the eclasses, |
15 |
>>> let me quote Zac: |
16 |
>>> |
17 |
>>> #gentoo-dev 20:19 <@zmedico> jmbsvicetto: it's only an issue for people |
18 |
>>> upgrading from less than portage-2.1.4, which is pretty rare nowadays |
19 |
>>> |
20 |
>>> |
21 |
>>> For the KDE team, |
22 |
>>> |
23 |
>> It's an issue for people who have packages in vdb emerged with portage |
24 |
>> older than 2.1.4 (if this was the version where the env started being |
25 |
>> added to vdb). I have been maintaining the position that nuking eclasses |
26 |
>> doesn't really provide enough benefits to bork these installs. I |
27 |
>> recommend just making the eclasses unusable for emerging stuff and |
28 |
>> keeping uninstalls working. |
29 |
> |
30 |
>> Regards, |
31 |
>> Petteri |
32 |
> |
33 |
> |
34 |
> Yeah, but how many people would really be affected by this? Also, I |
35 |
> talked to Zac about this and all an user would need to do to get Portage |
36 |
> to work again would be to grab the dropped eclasses. We could document |
37 |
> this and provide links to the eclasses or create a tarball with the |
38 |
> dropped eclasses. |
39 |
> Even though this could affect packages merged before portage-2.1.4, the |
40 |
> only packages that would be affected are packages that haven't had any |
41 |
> updates since then and that means the eclasses they may use are still |
42 |
> required and can not be dropped. So this will only affect users that |
43 |
> haven't synced and updated their system for over 1 year. |
44 |
> As I recall the issue about dropping eclasses being raised before and we |
45 |
> have 27 deprecated eclasses in the tree (as determined by grep |
46 |
> DEPRECATED $(portageq portdir)/eclass/* and that doesn't return all the |
47 |
> kde eclasses we would like to drop), should we postpone this issue |
48 |
> forever? The potential breakage will only diminish with time, so what |
49 |
> benefits are required to out weight it? |
50 |
> |
51 |
> |
52 |
|
53 |
What benefit does removing eclasses have besides a very minor space |
54 |
change and maybe marginally faster to find what eclass to use? |
55 |
|
56 |
Regards, |
57 |
Petteri |