| Summary: | Can't unmerge old package where eclass no longer exists | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Stuart Shelton <srcshelton> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I have an old package which I installed from a Portage overlay directory, which used a custom eclass. This eclass (and, indeed, the entire overlay) has now been removed. However, when I try to remove this package from my system, emerge aborts with the following error: >>> Unmerging x11-themes/lila-backgrounds-0.3.1... No package files given... Grabbing a set. QA Notice: ECLASS 'lila-artwork' inherited illegally in x11-themes/lila-backgrounds-0.3.1 /usr/lib/portage/bin/ebuild.sh: line 1319: /usr/portage/eclass/lila-artwork.eclass: No such file or directory !!! ERROR: x11-themes/lila-backgrounds-0.3.1 failed. !!! Function inherit, Line 1320, Exitcode 1 !!! died sourcing /usr/portage/eclass/lila-artwork.eclass in inherit() !!! FAILED prerm: 1 ... now I anticipate remarks about unsupported and out-of-tree ebuilds, etc. But my point is that if we're trying to *remove* a package, then shouldn't the packages files and metadata be removed even if the class is no longer available? Perhaps the eclass inherited by any installed ebuild should be stored alongside the package metadata if it is *vital* to the subsequent removal of said package? At least this way people aren't left with a stuck package. Note that I've solved this problem myself (I had a backup of the old eclass lying around - but I guess I could just have edited the installed ebuild to remove the inherit line) and have removed the package, but thought I'd report this as it seems to be a problem in portage that shouldn't be encountered. Thoughts? Cheers, Stuart