| Summary: | depclean complains about unresolved dependencies unless `emerge -uD world` is used prior | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Josef Reidinger <queen.killer> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 136244 | ||
|
Description
Josef Reidinger
2006-08-25 07:20:30 UTC
The code accounts for this case... What does 'emerge -evp virtual/ghostscript' give you? ghostscript-gpl or ghostscript-gnu? Ok, I've mostly figured out what's going on. (In reply to comment #0) > app-text/ghostscript-gpl required by virtual/ghostscript-0 !!! All ebuilds that could satisfy "ghostscript-gnu" have been masked. The preference is to use an unmasked ebuild over a masked installed package. Zac, others: new flag to be passed over to dep_zapdeps to alter this behaviour for depclean only or switch it altogether and have -uD fail more often? > x11-apps/luit required by x11-terms/xterm-215 x11-apps/luit is required as far as the ebuild goes when USE="unicode" and it appears that your xterm was compiled with USE="unicode". > ~dev-lang/perl-5.8.7 required by virtual/perl-MIME-Base64-3.05 > virtual/perl-Digest-MD5-2.33 virtual/perl-Test-Harness-2.48 > virtual/perl-PodParser-1.30 These all apears valid too. Do you have a different version of perl installed? This looks like it might be bugs with those specific virtuals... > x11-apps/xdpyinfo required by www-client/mozilla-launcher-1.49 > virtual/x11 required by media-libs/libwmf-0.2.8.2 > x11-apps/xmessage required by app-emulation/wine-0.9.8-r1 These three are all to do with virtual/x11. What does 'emerge -p virtual/x11' give you? (In reply to comment #2) > Ok, I've mostly figured out what's going on. > > (In reply to comment #0) > > app-text/ghostscript-gpl required by virtual/ghostscript-0 > > !!! All ebuilds that could satisfy "ghostscript-gnu" have been masked. > > The preference is to use an unmasked ebuild over a masked installed package. > Zac, others: new flag to be passed over to dep_zapdeps to alter this behaviour > for depclean only or switch it altogether and have -uD fail more often? > Hmm, interesting I use it and didn`t know it. > > x11-apps/luit required by x11-terms/xterm-215 > > x11-apps/luit is required as far as the ebuild goes when USE="unicode" and > it appears that your xterm was compiled with USE="unicode". > yes, that`s real error on my pc > > ~dev-lang/perl-5.8.7 required by virtual/perl-MIME-Base64-3.05 > > virtual/perl-Digest-MD5-2.33 virtual/perl-Test-Harness-2.48 > > virtual/perl-PodParser-1.30 > > These all apears valid too. Do you have a different version of perl installed? > This looks like it might be bugs with those specific virtuals... > I have this and update podparser needn`t that perl, this looks bad, because I have newer version user@localhost /tools $ emerge -p virtual/perl-PodParser These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] virtual/perl-PodParser-1.34 [1.30] user@localhost /tools $ emerge -p perl These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-lang/perl-5.8.8-r2 USE="-doc*" > > x11-apps/xdpyinfo required by www-client/mozilla-launcher-1.49 > > virtual/x11 required by media-libs/libwmf-0.2.8.2 > > x11-apps/xmessage required by app-emulation/wine-0.9.8-r1 > > These three are all to do with virtual/x11. What does 'emerge -p virtual/x11' > give you? > OK, I have xorg-x11-7.0, so I doesn`t see where is a problem? why this xorg server isn`t in virtual/x11? localhost xorg-x11 # X -version X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.16-gentoo-r9 i686 Current Operating System: Linux localhost 2.6.16-gentoo-r12 #1 PREEMPT Sat Jul 8 23:18:33 CEST 2006 i686 localhost xorg-x11 # emerge -p virtual/x11 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-text/rman-3.2 [ebuild N ] x11-themes/gentoo-xcursors-0.3.1 [ebuild N ] x11-apps/xdriinfo-1.0.1 USE="-debug" [ebuild N ] x11-misc/xorg-cf-files-1.0.2 USE="-debug" [ebuild N ] x11-misc/imake-1.0.2 USE="-debug" [ebuild N ] x11-libs/libXvMC-1.0.2 USE="-debug" [ebuild N ] x11-libs/libXprintUtil-1.0.1 USE="-debug" [ebuild N ] x11-libs/libXprintAppUtil-1.0.1 USE="-debug" [ebuild N ] x11-apps/xsetroot-1.0.1 USE="-debug" [ebuild N ] x11-apps/xcursorgen-1.0.1 USE="-debug" [ebuild N ] x11-themes/xcursor-themes-1.0.1 USE="-debug" [ebuild N ] x11-apps/xdpyinfo-1.0.1 USE="-debug" [ebuild N ] x11-libs/libXevie-1.0.1 USE="-debug" [ebuild N ] x11-libs/libXTrap-1.0.0 USE="-debug" [ebuild N ] x11-apps/xdm-1.0.5 USE="pam -debug -ipv6 -xprint" [ebuild N ] x11-libs/libFS-1.0.0 USE="-debug -ipv6" [ebuild N ] x11-libs/liboldX-1.0.1 USE="-debug" [ebuild N ] x11-misc/gccmakedep-1.0.2 USE="-debug" [ebuild N ] virtual/x11-7.0-r2 USE="dri" another think is, that I emerge wine without problems and wine need`t xmessage, so why now it missing it? I know I didn`t unmerge it. So, it write, that libwmf need virtual/x11, emerge tells me that I doesn`t have it but when I write emerge -p libwmf it white: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-libs/libwmf-0.2.8.4 [0.2.8.2] USE="gd% gtk% xml% -debug% -doc% -expat%" they need x11/virtual, but don`t emerge it when it missing, I am really confused (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > ~dev-lang/perl-5.8.7 required by virtual/perl-MIME-Base64-3.05 > > > virtual/perl-Digest-MD5-2.33 virtual/perl-Test-Harness-2.48 > > > virtual/perl-PodParser-1.30 > > > > These all apears valid too. Do you have a different version of perl installed? > > This looks like it might be bugs with those specific virtuals... > > I have this and update podparser needn`t that perl, this looks bad, because I > have newer version <snip> > [ebuild U ] virtual/perl-PodParser-1.34 [1.30] > [ebuild R ] dev-lang/perl-5.8.8-r2 USE="-doc*" Yep, one of the major snags of portage. It won't ensure your system is kept in a sane state when upgrading individual packages. Upon closer inspection, there's virtuals set aside for newer perl versions as the update above shows. > > > x11-apps/xdpyinfo required by www-client/mozilla-launcher-1.49 > > > virtual/x11 required by media-libs/libwmf-0.2.8.2 > > > x11-apps/xmessage required by app-emulation/wine-0.9.8-r1 > > > > These three are all to do with virtual/x11. What does 'emerge -p virtual/x11' > > give you? > > OK, I have xorg-x11-7.0, so I doesn`t see where is a problem? why this xorg > server isn`t in virtual/x11? <snip> > [ebuild N ] virtual/x11-7.0-r2 USE="dri" virtual/x11 is now an actual package with individual ebuilds. However, this is purely a backwards compatibility thing as far as I know. > another think is, that I emerge wine without problems and wine need`t xmessage, > so why now it missing it? I know I didn`t unmerge it. This would appear to be due to the above-mentioned deprecation of virtual/x11. xorg-x11 split into many packages when it went to 7.0. Ebuilds should now be depending on only the individual required packages rather than the "full blown" X11 installation that virtual/x11 represents. Depclean uses PORTDIR's ebuilds for dependency information when it can in order to ensure/improve accuracy. It would appear that the version of wine you installed only had a dependency on virtual/x11. It was then updated to include the >=7.0 type dependencies. So, while you didn't unmerge xmessage, you did unmerge xorg-x11-6.8? > So, it write, that libwmf need virtual/x11, emerge tells me that I doesn`t have > it but when I write emerge -p libwmf it white: > > [ebuild U ] media-libs/libwmf-0.2.8.4 [0.2.8.2] USE="gd% gtk% xml% -debug% > -doc% -expat%" > > they need x11/virtual, but don`t emerge it when it missing, I am really > confused The 0.2.8.2 version is old and depends on the deprecated virtual/x11. 0.2.8.4 depends only on the specific subpackages needed in the same way as wine above. (In reply to comment #4) > <snip> > > [ebuild U ] virtual/perl-PodParser-1.34 [1.30] > > [ebuild R ] dev-lang/perl-5.8.8-r2 USE="-doc*" > > Yep, one of the major snags of portage. It won't ensure your system is kept in > a sane state when upgrading individual packages. Upon closer inspection, > there's virtuals set aside for newer perl versions as the update above shows. > Hmm, but I upgrade whole system at same time, so when i type emerge -pvu world it doesn`t write [ebuild U ] virtual/perl-PodParser-1.34 [1.30] thanks for your ample answers (In reply to comment #5) > (In reply to comment #4) > > Yep, one of the major snags of portage. It won't ensure your system is kept in > > a sane state when upgrading individual packages. Upon closer inspection, > > there's virtuals set aside for newer perl versions as the update above shows. > > > > Hmm, but I upgrade whole system at same time, so when i type emerge -pvu world > it doesn`t write > [ebuild U ] virtual/perl-PodParser-1.34 [1.30] If you add --deep (-D) to your parameters to emerge a whole lot more updates will likely appear. Without specifying --deep emerge will stop checking for updates in a dependency chain when it hits a package that doesn't need updating. --deep tells emerge to continue on. Adding --deep will likely not only show updates but also a bunch of new packages as well which will likely include all the ones that depclean is complaining about - other than ghostscript-gnu. > thanks for your ample answers No worries. I don't do much else nowadays, so I should at least thoroughly investigate possible problems with code that I do contribute. ;) (In reply to comment #2) > (In reply to comment #0) > > app-text/ghostscript-gpl required by virtual/ghostscript-0 > > !!! All ebuilds that could satisfy "ghostscript-gnu" have been masked. > > The preference is to use an unmasked ebuild over a masked installed package. > Zac, others: new flag to be passed over to dep_zapdeps to alter this behaviour > for depclean only or switch it altogether and have -uD fail more often? Well, maybe the current behavior is acceptable? Maybe we should just add a note to the depclean warning message that they should run `emerge -uD world` first. That way they'll be forced to resolve the issues reported in this bug before they run depclean. In svn r4344 I've added a recommendation to run `emerge --update --deep world` in the warning message and an additional reminder when depclean exits due to unresolved dependencies. Ok, so that's all the points on this bug resolved then? Hmm, running -uD world (or even -uDN) would not actually be enough. The problem was that the explicitly chosen || () provider had been masked. Running -uD world would just emerge the default provider rather than giving any information as to the provider's masking status. The following depclean would then remove the masked package... Is that good, bad, acceptable, or what? :) Heh.. I guess it's acceptable as the system will end up being in a sane state with the removable masked packages removed. Thinking about it, other options are just as imperfect. Ok, as it stands is fine I guess - at least the behaviour is well defined and recipricol. The `emerge -uD world` recommendation is in 2.1.1_rc1. |
