| Summary: | portage-2.2_rc62 depclean disagrees with @world -epv | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Steffen Schaumburg <steffen> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | steffen |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Output of emerge world -epv | ||
|
Description
Steffen Schaumburg
2010-02-19 17:05:07 UTC
Created attachment 220367 [details]
Output of emerge world -epv
(In reply to comment #0) > steffen ~ # emerge palapeli -pv > [...] > !!! All ebuilds that could satisfy "kde-base/palapeli" have been masked. > !!! One of the following masked packages is required to complete your request: > - kde-base/palapeli-4.4.0 (masked by: ~amd64 keyword) > > In my understanding emerge ought to demand that I downgrade packages such as > this one, or give me a blocker, or something. But it says there's nothing to do > on world -epv as well as well world -DuNpv. Note that I have --with-bdeps=y in > my EMERGE_DEFAULT_OPTS. There's no versions of palapeli to downgrade to because there's only one versions and it's masked. > In any case, emerge world -e ought to abort or complain > if there is a dependency missing (as clearly is, palapeli doesnt show up in the > output of world -epv), right? Well, emerge -e world is somewhat tolerant of certain issues because usually it's more useful that way. > Any ideas what I can do about this? I would try the latest svn but as I > understand #304129 it wouldn't work for me anyways, but I'm happy to try > newer/older versions, just tell me which please :) You might want to consider reinstalling from scratch. It's not always easy or even feasible to do a massive downgrade like you want. First of all, thanks, that was quick :) > There's no versions of palapeli to downgrade to because there's only one > versions and it's masked. >> In any case, emerge world -e ought to abort or complain >> if there is a dependency missing (as clearly is, palapeli doesnt show up in the >> output of world -epv), right? > Well, emerge -e world is somewhat tolerant of certain issues because usually > it's more useful that way. I got to be honest I can't see any case in which it could be useful but I'll take your word for it. And I do appreciate that mine is a pretty extreme borderline case (package.keywords has ~600 entries) so I don't expect anyone to change portage and break other people's more common setups. However, maybe some compromise can be reached, e.g. how about emerge -e world issuing a warning like one of these two: a) "Note: Not all dependencies could be resolved." b) "Note: Not all dependencies could be resolved. Packages with missing dependencies include but may not be limited to: package1, package2" I don't know the internals, but if option a) could be easily implemented I think that would be great - it doesn't tell you quite what's wrong, but at least you know THAT something is potentially wrong. >> Any ideas what I can do about this? I would try the latest svn but as I >> understand #304129 it wouldn't work for me anyways, but I'm happy to try >> newer/older versions, just tell me which please :) >You might want to consider reinstalling from scratch. It's not always easy or >even feasible to do a massive downgrade like you want. Oh I don't want to downgrade, exactly because I would expect that it is beyond even the best package manager called portage ;) I want to keep all ~ versions I have and get rid of the testingness of my install by "natural stabelisation" (is that a word?). E.g. currently I have xorg-server-1.7.5, so I'll keep that until it's either stable or removed (in which case I'd upgrade and the game begins again). As it is however I now have packages installed without a resolvable dependency tree, so it's quite feasible that I'll miss vital updates incl. security-relevant ones. Can you think of any manual way to get to the "missing packages", e.g. is there a way to get depclean to print of a list of what it feels are the necessary packages? Then I could run a script on that to find the missing ones. Apologies, clear case of RTFM. I got the list (equery list '*'). But what do you think of my suggestion for the warning? Expectation after a successful run of emerge world -e is that everything is re-merged, since that will not be the case I really think a small notice at least would be very good. It should it already say something like this: !!! The following installed packages are masked: blah blah blah... Doesn't emerge world -e do that for you? No, it doesn't give any warning at all. This little one-liner produces a list of lines for package.keywords: equery -N list '*' | grep "M\~" | cut -d ' ' -f 3 | sed 's/$/ ~amd64/g' | sed 's/^/~/g' If I try one from the list e.g. emerge openrc -av1 it gives an appropriate error - I picked a great example, as I seem to be running openrc-0.5.3 which isn't even in the tree anymore. As another example, I have libssh-0.4.0 installed which is unstable, there's an older stable and also a newer unstable version. If I try emerge libssh -av1 it (correctly) offers a downgrade, but emerge world -DuNpv says there's nothing to do. To save you the hassle of working out the dep tree (all snipped after the first entry and useless stuff removed):
steffen ~ # equery depends libssh
kde-base/kdebase-kioslaves-4.4.0 (sftp ? >=net-libs/libssh-0.4.0[sftp])
steffen ~ # equery depends kde-base/kdebase-kioslaves
kde-base/kdebase-runtime-meta-4.4.0 (!kdeprefix ? >=kde-base/kdebase-kioslaves-4.4.0[aqua=,-kdeprefix])
(kdeprefix ? >=kde-base/kdebase-kioslaves-4.4.0:4.4[aqua=,kdeprefix])
steffen ~ # equery depends kde-base/kdebase-runtime-meta
kde-base/kdebase-meta-4.4.0 (!kdeprefix ? >=kde-base/kdebase-runtime-meta-4.4.0[aqua=,-kdeprefix])
(kdeprefix ? >=kde-base/kdebase-runtime-meta-4.4.0:4.4[aqua=,kdeprefix])
steffen ~ # equery depends kde-base/kdebase-meta
kde-base/kde-meta-4.4.0 (!kdeprefix ? >=kde-base/kdebase-meta-4.4.0[aqua=,-kdeprefix])
(kdeprefix ? >=kde-base/kdebase-meta-4.4.0:4.4[aqua=,kdeprefix])
steffen ~ # grep "kde-meta" /var/lib/portage/world
kde-base/kde-meta
Sorry I seem to be suffering from "second post syndrome" today, I'm moving soon so there's a lot on my mind.
Oh, the reason you don't see mask messages is that KEYWORDS mask messages are suppressed because people complained about them. I guess we should show them for emerge -e mode though. That would be perfect yes. I'll go ahead and fix up my system now doesn't sound like it'll be difficult to verify when the portage change has been done. Whilst cleaning I noticed another closely related issue with xerces-c, I think the error that comes when I remove the package and then run emerge world -DuN puts it better than I can: emerge: there are no ebuilds built with USE flags to satisfy ">=dev-libs/xerces-c-3[icu]". !!! One of the following packages is required to complete your request: - dev-libs/xerces-c-3.0.1-r1 (Change USE: +icu) (dependency required by "games-strategy/glest-3.2.2" [installed]) (dependency required by "@world" [argument]) Same issue but with USE-related error, IMHO, so should be brought up (or at least not silently skipped) by emerge world -e. I'm getting increasingly confused as to under what exact circumstances the problem of skipping packages with missing keywords occurs. Here's my results so far (note: I made a couple of changes since the original bugreport): Total packages installed/needed as reported by depclean and equery: 1374 Skipped packages that are dependencies of installed packages and are only available as testing: 27 Skipped packages that are dependencies, where a downgrade to stable is possible (but not suggested by @world -DuN nor @world -e, the latter also doesn't want to rebuild the package in question and neither gives any warning/error message): 7 One possible explanation is that portage fails to report/recompile/warn-about/want-to-downgrade installed packages with missing keyword if: - it is not in world and only available as ~ or - it is not in world and a certain version of it is required, and that can only be fulfilled by a version that is ~ But I'm not certain if I list the constraints with maximum tightness, nor if there are other conditions that cause this bug to appear. (In reply to comment #10) > Same issue but with USE-related error, IMHO, so should be brought up (or at > least not silently skipped) by emerge world -e. I suspect that the instance of xerces-c that you had installed was built with USE=icu, and that's why there was no error message in that case. (In reply to comment #11) > I'm getting increasingly confused as to under what exact circumstances the > problem of skipping packages with missing keywords occurs. Essentially, it skips anything for which there no available ebuild that is not masked in any way. This can be helpful if you intentionally want to skip packages by masking them with package.mask, but in your case, it would be better to have an error message about packages masked by KEYWORDS. |
