Hola y'all. Reiterating something; eclasses can *never* be removed. Doesn't matter if they're not in use, they cannot be removed due to the fact anyone who installed that ebuild cannot remove the ebuild without knowing about the touch trick to make it play nice. PHP: I've brought this up before, and it was brushed off; re-raising the issue now since users *still* are hitting it. php-2.eclass, and php.eclass need to be restored. Gut the setup->install functionality if you want, but everything post install is needed, *especially* the rm funcs. inst funcs should be left in so you're not breaking peoples binpkgs, but rm has to be restored so people can at least unmerge the affected pkgs without hitting an immediate inherit failure. QT: yeah, qt was renamed to qt3; you still need qt lingering. Next major portage release relaxes this; that said forcing people to upgrade to a massively different portage just to unmerge stuff is invalid. So... kindly restore the relevant eclass functionality into the tree, and sign off here.
Qt was installed before qt3 for one day and the only package that used it was package.masked and arch flagged as -*, so I hardly think restoring it is a priority.
week for the eclass actually (looking at cvs); even if it was masked it really shouldn't be yanked due to the aforementioned rm issues. Yeah, it's damn annoying, and a sign of portage stupidity, but is what it is. That said, yet to see user complaints/bugs regarding it, although restoration of it *is* proper. I reserve the right to berate you down the line if a user pops up with with inherit issues from that eclass :P Aside from that, the php eclasses still stand. See a user every few weeks who hits it.
ok, please list the functions that need to continue to exist in the restored PHP eclasses. I honestly do NOT want people even using binpkgs to install those old versions anymore. rm stuff yes, install from source or binpkg no.
horking their binpkgs doesn't really fly. Re: what needs to be restored, look through the eclasses; if it's related to post install phases, it needs to be there. Technically people aren't supposed to even yank the eclasses, but leaving the post install stuff is enough to keep things from breaking (so it's what's required). If there isn't any relevant functionality for post install stuff, then just touching the bugger is enough.
beratement is okay :) that said, one class that probably DOES need to be restored is kde-i18n.eclass.
I'm not after breaking their binpkg, just stopping them from using them. They will NOT work with anything else current. php_pkg_preinst() { die "Sorry, you need to recompile a newer version of PHP" }
Ok, I've restored php.eclass/php-2.eclass. I've taken measures to stop ANY package from using their unpack/compile/install functions, as I really really want people away from these eclasses. The preinst/postinst doesn't do die anymore, but spits out errors instead. If anybody gets them, they are responsible for it themselves - any bugs from it will be closed with WONTFIX/INVALID. We stopped supporting the old versions of PHP more than a year ago, after providing a 6 month migration window to the new PHP eclasses. If somebody is still using a PHP package thats more than a year old, they should be using an old portage snapshot, not the latest tree.
Yo. Restore the eclasses, pronto. Users are still hitting it, and will hit in increasing numbers when the become aware of bloat in their world file (iow the problem is going to get worse rather quickly). caleb, kde-i18n.eclass needs to be restored, and do something about qt.eclass
removing php-bugs as I have restored those eclasses already.
(In reply to comment #8) > kde-i18n.eclass needs to be restored Committed an empty placeholder. > do something about qt.eclass It existed only a few hours for testing so I think it's there's nothing to do about it.
(In reply to comment #9) > removing php-bugs as I have restored those eclasses already. Now really removed... :)
If a user hits the qt.eclass problem, please send them my way.
I think this has all be fulfilled.
