I detected this problem when deleting a private eclass from my overlay directory before unmerging the ebuild, which depends on that eclass. Not a big deal for me, I just removed the stuff by hand, but in general having really old ebuilds in use, whose eclasses do not exist anymore or changed in an unexpected way since the ebuild was written, could cause serious trouble.
problem sighted "in the wild" (forums.g.o)
lowering priority again, it was BreakMyGentoo stuff
Using what portage?
I think it was 2.0.50-r1 or 3. But - as I wrote - it was a local problem in my overlay directory. The question is, what happens when someone doesn't keep all ebuilds up to date: 1. Does portage check /var/db/pkg/*/*/ before a deprecated eclass gets removed or is there any other update-mechanism? 2. What happens when a particular installed ebuild isn't compatible with a newer version of an eclass? Maybe the ebuild overrides a function, but doesn't calls the inherited function because it's not needed, but in a later version of the eclass, it is!?
Didn't realized it first, but here's a "valid" missing_eclass_sample: http://forums.gentoo.org/viewtopic.php?p=1062142
A simple solution for deprecated eclasses would be to put them in e.g. /usr/portage/eclass/deprecated and include these when unmerging an ebuild. Then portage has to check, if the ebuild inherits a deprecated eclass. If yes, portage has to check the whole /var/db tree, if there's another reference. If not, the eclass could be safely deleted from /usr/portage/eclass/deprecated. This will be the most common problem and the advantage is that this will perfectly fit in the way portage works, while trying to update old installed ebuilds could cause more problems. And remerging may be no option in some cases. The downside: This won't solve the second problem.
A better solution to this is to correctly save and restore the env (instead of resourcing the ebuild *every* single phase). Marking this blocked by #56408, since w/ the env patches I have there, this type of problem isn't possible.
I have a far simpler "method" - at least as long as we have no uninstall stuff to perform, beside grabbing the set of files and removing it. Testing if the eclass exist and if not touching it, satifies portage.
Err... No. No no no no... :) Right now I'm not aware of any eclass's that provide prerm/postrm. There are a few that provide setup. If portage just basically ignores the missing eclass (as you're proposing), that lets portage get into an even worse unknown state; it thinks things are fine, when they are not. What if the setup/(pre|post)(rm|inst) calls a function defined by that eclass? That becomes a bug that ebuild.sh will overlook (specifically all ebuilds overlook it). You rarely see pkg_setup() { webapp_setup || die "wtf" } for example. The correct solution that is to reuse the saved env. Sidestepping/hiding the problem only allows the situtation to become worse.
I knew I would get this answer. ;) Didn't thought about something like 'webapp_setup || die "wtf"' And indeed, there are eclasses doing rm stuff.
*** Bug 60919 has been marked as a duplicate of this bug. ***
Run into this while upgrading php from 4.3.3-r1 to 4.3.8. ("/usr/sbin/ebuild.sh: line 1102: /usr/portage/eclass/php.eclass: No such file or directory").
*** Bug 69813 has been marked as a duplicate of this bug. ***
Would this be a reasonable unmerging strategy for Portage: 1 If an ebuild does not override any functionality for unmerging, then the ebuild script won't be run during unmerge. Portage just deletes all merged files. 2 Else if all eclasses (+ other dependencies, are there such? DEPEND, RDEPEND, UDEPEND...) can be found, Portage acts just like it does now. 3 Else it retrieves the needed dependency from CVS. Note that the newest version of the dependency is retrieved, not the one matching the ebuild merge date. This way bug fixes can take effect. Note that here we assume that eclass APIs and their semantics will always be backwards compatible, and this is always a fair assumption regarding software components. ---- If there is need to change the contract between eclass and ebuilds depending on it - and this seems to be the case, for otherwise this bug hadn't been reported (the existence of an eclass clearly is part of the contract :-) - the following needs to be done: The developer creates a new "slot" for the eclass. It might be fairly easy to utilize the current version and slot handling functionality of Portage. When no current ebuild uses an old eclass or eclass slot anymore, Portage removes it, but to avoid the need for step 3 above (CVS retrieval), Portage checks if any of the merged ebuilds refers to it, in which case it saves it in an attic directory. Step 2 above uses this directory when deciding if there is need for step 3. Note that the strategy above can be implemented without this slot functionality.
Will portage be able to unmerge the old mod_php soon? Or should I do something manually? (yuck :-)
Future portage versions will. This is in regard to php.eclass, yes? If so... robbat2, here is an example of the horkage I was talking about.
*** Bug 101095 has been marked as a duplicate of this bug. ***
*** Bug 105464 has been marked as a duplicate of this bug. ***
*** Bug 134939 has been marked as a duplicate of this bug. ***
Why not just save everything needed to build the package in the /var/db/pkg db? (including the eclass files)
mainly because it's basically already there (environment.bz2) and it'd be a super-redundancy.
This is fixed in 2.1.4_rc1.
