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
signature.asc
Description: OpenPGP digital signature
