Jorge Manuel B. S. Vicetto wrote:
> Petteri Räty wrote:
>> Jorge Manuel B. S. Vicetto wrote:
>>> Hi.
>>>
>>> As the KDE team prepares to add revised eclasses for the KDE3 ebuilds so
>>> we can get 3.5.10 marked stable and then finally ask for KDE4
>>> stabilization, we'd like to drop some old eclasses from the tree. We
>>> plan to drop the kde-base, kde-dist, kde-i18n and kde-source eclasses as
>>> they're no longer used.
>>> So unless someone has any objections, we'll drop the eclasses from the
>>> tree in the next few days.
>>>
>>> In case anyone has any doubts about portage reliance on the eclasses,
>>> let me quote Zac:
>>>
>>> #gentoo-dev 20:19 <@zmedico> jmbsvicetto: it's only an issue for people
>>> upgrading from less than portage-2.1.4, which is pretty rare nowadays
>>>
>>>
>>> For the KDE team,
>>>
>> It's an issue for people who have packages in vdb emerged with portage
>> older than 2.1.4 (if this was the version where the env started being
>> added to vdb). I have been maintaining the position that nuking eclasses
>> doesn't really provide enough benefits to bork these installs. I
>> recommend just making the eclasses unusable for emerging stuff and
>> keeping uninstalls working.
> 
>> Regards,
>> Petteri
> 
> 
> Yeah, but how many people would really be affected by this? Also, I
> talked to Zac about this and all an user would need to do to get Portage
> to work again would be to grab the dropped eclasses. We could document
> this and provide links to the eclasses or create a tarball with the
> dropped eclasses.
> Even though this could affect packages merged before portage-2.1.4, the
> only packages that would be affected are packages that haven't had any
> updates since then and that means the eclasses they may use are still
> required and can not be dropped. So this will only affect users that
> haven't synced and updated their system for over 1 year.
> As I recall the issue about dropping eclasses being raised before and we
> have 27 deprecated eclasses in the tree (as determined by grep
> DEPRECATED $(portageq portdir)/eclass/* and that doesn't return all the
> kde eclasses we would like to drop), should we postpone this issue
> forever? The potential breakage will only diminish with time, so what
> benefits are required to out weight it?
> 
> 

What benefit does removing eclasses have besides a very minor space
change and maybe marginally faster to find what eclass to use?

Regards,
Petteri