| Summary: | automatically unmask a package and it's dependencies | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Michal Suchanek <hramrach> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | blubb, ejona86, jakub, radek |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Michal Suchanek
2006-06-13 04:15:15 UTC
*** Bug 136641 has been marked as a duplicate of this bug. *** Please post the exact command and it's output. Also, please attach the output of `emerge --info`. emerge -tvauD world These are the packages that would be merged, in reverse order: Calculating world dependencies - !!! All ebuilds that could satisfy "<=x11-base/xorg-x11-6.99" have been masked. !!! One of the following masked packages is required to complete your request: - x11-base/xorg-x11-6.9.0-r1 (masked by: package.mask, package.mask, ~x86 keyword) # I do not want to go back to xorg .. but packages depending on virtual/x11 pull it in - x11-base/xorg-x11-6.8.2-r7 (masked by: package.mask) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "virtual/xft-6.8" [ebuild]) !!! Problem resolving dependencies for sys-apps/portage !!! Depgraph creation failed. hp-tc2110 hramrach # equery d virtual/xft [ Searching for packages depending on virtual/xft... ] net-libs/gecko-sdk-1.7.13 x11-libs/fltk-1.1.7 x11-libs/pango-1.10.3 x11-libs/cairo-1.0.4 x11-libs/vte-0.12.2 app-office/abiword-2.2.11 hp-tc2110 hramrach # emerge -s virtual/xft Searching... [ Results for search key : virtual/xft ] [ Applications found : 0 ] Portage 2.1 (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r3, 2.6.15-gentoo-r4 i686) ================================================================= System uname: 2.6.15-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.12.0 ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks maketest metadata-transfer nostrip sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.sh.cvut.cz/MIRRORS/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage//packages/x86/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac accessibility aim alsa apache2 berkdb bzip2 cairo canna crypt cups debug dga dlloader dmx doc dri dts dvd dvi examples fbcon ffmpeg firefox flac foomaticdb fpx gif gimpprint glitz glut gnutls gpm gs gtk hardened icq icu ipv6 irc jabber java jbig jpeg kerberos krb4 lcms ldap libclamav matroska mmx mng mono mp3 mpeg msn nas ncurses nls nodrm nptl nptlonly nsplugin offensive ogg opengl pam pic png ppds readline samba sasl speex spell sse ssl svg tcpd theora threads tiff truetype truetype-fonts unicode userlocales vcd vorbis win32codecs wmf x86 xml xml2 xorg xosd xv zlib elibc_glibc input_devices_evdev input_devices_mouse input_devices_keyboard input_devices_kbd input_devices_joystick kernel_linux userland_GNU video_cards_mga video_cards_radeon video_cards_ati" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS (In reply to comment #4) > (dependency required by "virtual/xft-6.8" [ebuild]) The above part of the message is a clue that it's pulling in the wrong version of virtual/xft. I realize that it's not an optimal solution, but you could mask <virtual/xft-7.0 and give the resolver another chance. My instinct suggests that part of the problem is || ( ( modular deps ) virtual/x11 ) circular dependencies as discussed in bug 133671. Could you attach the output of the same emerge command with --debug enabled? Quite frankly, the proper solution here is to get rid of the bogus virtual/x11-7* which is only hiding breakage and breaking more stuff on its way. And BTW, p.masking <virtual/xorg-7.0 is _not_ a proper way to p.mask non-modular X. You should p.mask <x11-base/xorg-x11-7.0 instead, not the fake semi-virtual/semi-metabuild. I have modular X installed, yet virtual/x11-7* is _not_ installed. You are masking a wrong thing. And, you are in fact asking here to hack resolver to hide real bugs even more. The whole problem here is that you did hit an ebuild unported for modular X. The proper action is to fix those ebuilds, not to hack portage. FWIW, the unported ebuilds' bugs would be way more visible and less cryptic if there was no virtual/x11-7*, as noted in Comment #6. There is virtual/xft-7.0 in portage. I had the same problem but just needed to give it ~amd64 in package.keywords. That allowed the packages that required xft to use 7.0 instead of 6.8 and did not require <xorg-x11-7 (In reply to comment #6) > Quite frankly, the proper solution here is to get rid of the bogus > virtual/x11-7* which is only hiding breakage and breaking more stuff on its > way. What does it break? Are you saying that all new-style virtuals are bogus? (In reply to comment #9) > (In reply to comment #6) > > Quite frankly, the proper solution here is to get rid of the bogus > > virtual/x11-7* which is only hiding breakage and breaking more stuff on its > > way. > > What does it break? It breaks dependencies for ebuilds that actually are already fixed for modular X. So, it hides real bugs in unported ebuilds and causes more troubles along the way. Please, refer to the recent thead on gentoo-dev mailing list. http://tinyurl.com/ny342 > Are you saying that all new-style virtuals are bogus? No. :) If I understand correctly then, it's improper dependencies in the virtual/x11-7.0 ebuild that causes problems? Anyway, portage seems to behave correctly... The problem here is that there is virtual/xft-7 or somesuch but portage does not tell me. Anotherp roblem of this kind is with xf86-video-ati. I masked xorg-server 1.1 because it crashes a lot. The latest version of xf86-video-ati requires xorg-server 1.1 so it would not work. I removed it and tried to emerge xf86-video-ati again. Now portage complined that xf86-video-ati requires the new X server. I had to mask the 6.6 version, and the older version emerged without problems then. So the general problem is: Package a-1 depends on b-1, and a-1 is requested directly or indirecly as a dependency. Portage goes to great detail as to why b-1 cannot be installed. But it does not say that there exists a-0 (the case with video driver) that is ready to be installed (but older version) or a-2 (the case with xft) which could be installed but is masked. Since the recommended way to install unstable packages is to keyword them one by one this problem is bound to be quite common. Resetting the summary. This is not about pulling the wrong package. (In reply to comment #12) > The problem here is that there is virtual/xft-7 or somesuch but portage does > not tell me. It doesn't tell you, because the depgraph is broken. If it wasn't broken, portage would not moan and would emerge it. If you p.mask/p.keyword something improperly, then it's not exactly fair to blame portage for your mistake. That's what documentation is for, not portage messages doing some guess-work for you. > Since the recommended way to install unstable packages is to keyword them one > by one this problem is bound to be quite common. No, if installing unstable packages on stable system, you should p.keyword all the needed dependencies as well. (In reply to comment #14) > (In reply to comment #12) > > The problem here is that there is virtual/xft-7 or somesuch but portage does > > not tell me. > > It doesn't tell you, because the depgraph is broken. If it wasn't broken, Why does it report ay errors at all then? The depgraph should not be broken if you do things properly :P > portage would not moan and would emerge it. If you p.mask/p.keyword something > improperly, then it's not exactly fair to blame portage for your mistake. > That's what documentation is for, not portage messages doing some guess-work > for you. What documentation tells me that there is virtual/xft-7.0? I am eager to read such documenation. I want to know everything about every package that will ever be in portage :) It would sure save much time searching for packages. > > > Since the recommended way to install unstable packages is to keyword them one > > by one this problem is bound to be quite common. > > No, if installing unstable packages on stable system, you should p.keyword all > the needed dependencies as well. But how do I tell I want to unmask virtual/xft? Protage cannot search for virtual packages. Even if it could, it does not search for masked packages. It is a new dependency. I did not need it before. I do have a verssion of virtual/x11 available. It just depends on xorg. (In reply to comment #14) > No, if installing unstable packages on stable system, you should p.keyword all > the needed dependencies as well. > Or to put it simply: portage has to tell me about the dependencies. Otherwise how do I tell if the dependency is already stable or an unastable package is needed for it? Unless I am supposed to keyword _all_ dependencies in which case I could just set ACCEPT_KEYWORDS to ~x86 because almost every package ultimately depends on glibc, etc. (In reply to comment #15) > Why does it report ay errors at all then? The depgraph should not be broken if > you do things properly :P Huh? _You_ have broken the depgraph by masking stuff improperly/not unmasking it properly. Or, a broken ebuild has broken the depgraph because it's not ported for modular X. What does portage have in common with this? > What documentation tells me that there is virtual/xft-7.0? I am eager to read > such documenation. I want to know everything about every package that will ever > be in portage :) It would sure save much time searching for packages. http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-packages.txt > But how do I tell I want to unmask virtual/xft? Protage cannot search for > virtual packages. Even if it could, it does not search for masked packages. It > is a new dependency. I did not need it before. I do have a verssion of > virtual/x11 available. It just depends on xorg. Did you ever read the message portage spits out, and tried to grok it? It tells you exactly what's wrong. Or, did you just feel like producing a little rant on bugzilla? Anyway, I'd suggest that you don't mix stable and unstable stuff if you can't cope with keywording needed ebuilds in /etc/portage/package.keywords, will save you the trouble. ;) (In reply to comment #17) > (In reply to comment #15) > > Why does it report ay errors at all then? The depgraph should not be broken if > > you do things properly :P > > Huh? _You_ have broken the depgraph by masking stuff improperly/not unmasking > it properly. Or, a broken ebuild has broken the depgraph because it's not > ported for modular X. What does portage have in common with this? Oh so you propose that portage is already way too verbose, and that any dependency problem should be reported this way: "Your dependency graph is broken. Fix it." ? After all, portage has nothing to do with it. It just parses the graph, and if it appears correct it merges something. > > > What documentation tells me that there is virtual/xft-7.0? I am eager to read > > such documenation. I want to know everything about every package that will ever > > be in portage :) It would sure save much time searching for packages. > > http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml > http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-packages.txt That's nice. It lists the packages that belong to modular X.org. But what will I do when I want to merge a package that does not belong to X? There aren't dependencies exclusively between X packages, are they? > > > > But how do I tell I want to unmask virtual/xft? Protage cannot search for > > virtual packages. Even if it could, it does not search for masked packages. It > > is a new dependency. I did not need it before. I do have a verssion of > > virtual/x11 available. It just depends on xorg. > > Did you ever read the message portage spits out, and tried to grok it? It tells > you exactly what's wrong. Or, did you just feel like producing a little rant on Yes, I tried to grok what portage told me. I did not understand it so I asked on irc. They told me that there is a newer version of virtual/xft. With that knowledge the problem is clear. But nobody so far answered the quiestion how could I tell (for arbitrary package that is not unmasked) that I need it ot that it even exists. You told me to read documantation but did not even sketch the solution to the problem. What would you expect? Now you point me to documantation that solves the problem for X packages in particular. But this is not X problem, it is a general dependency problem. When a package is requested (either on command line or as a dependency) portage chooses the latest version that is not masked, and tries to satisfy dependencies for that. If that fails it explains why the dependencies for that particular version cannot be satisfied. It is fine as long as installing this particular version is the right thing. However, portage does not (afaict) provide any diagnostics wether the choice portage did for me was right to start with. There might be a lower version of the package for wich the dependencies are already satisfied or a higher version of the package that is still masked. I do not know how to find out. Sure I can read all the involved ebuilds myself. If I can find out which are involved. But why do we have portage then? We can also run ebuilds manually. > bugzilla? Anyway, I'd suggest that you don't mix stable and unstable stuff if > you can't cope with keywording needed ebuilds in /etc/portage/package.keywords, > will save you the trouble. ;) I have no rpoblem with adding more packages to package.keywords as long as I can find out _what_ package to add. *** This bug has been marked as a duplicate of 79606 *** No, this is not dupe of that bug either. There are not any blocks involved in this. And it is not about resolving but about stating what is wrong. The message produced by portage is fine. What you really need is a tool that will automatically unmask a desired package and it's dependencies as necessary to complete the depgraph. That is one possible solution to part of the problem. The auto-unmasking would also solve another problem: after unmasking the direct dependencies of a package unmasking dependencies of dependencies may be needed. A tool for automating that would certainly be helpful. The other part is packages that have a masked (intentionally - because it is broken) dependency in their latest version but have an earlier version that can be merged fine. But the auto-unmasking probably covers most cases. (In reply to comment #22) > But the auto-unmasking probably covers most cases. Historically there has been lots of resistance to including a tool like this with portage. There is a perl script that does it posted here: http://article.gmane.org/gmane.linux.gentoo.user/128238 Lot of heated "discussion" here, eh? ;) (In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #15) > > > Why does it report ay errors at all then? The depgraph should not be broken if > > > you do things properly :P > > > > Huh? _You_ have broken the depgraph by masking stuff improperly/not unmasking > > it properly. Or, a broken ebuild has broken the depgraph because it's not > > ported for modular X. What does portage have in common with this? > > Oh so you propose that portage is already way too verbose, and that any > dependency problem should be reported this way: "Your dependency graph is > broken. Fix it." ? Portage already gives as much information as it reasonably can. <sarcasm> > After all, portage has nothing to do with it. It just parses the graph, and if > it appears correct it merges something. </sarcasm> > > > But how do I tell I want to unmask virtual/xft? Protage cannot search for > > > virtual packages. Even if it could, it does not search for masked packages. It > > > is a new dependency. I did not need it before. I do have a verssion of > > > virtual/x11 available. It just depends on xorg. > > > > Did you ever read the message portage spits out, and tried to grok it? It tells > > you exactly what's wrong. Or, did you just feel like producing a little rant on > > Yes, I tried to grok what portage told me. I did not understand it so I asked > on irc. They told me that there is a newer version of virtual/xft. With that > knowledge the problem is clear. But nobody so far answered the quiestion how > could I tell (for arbitrary package that is not unmasked) that I need it ot > that it even exists. ... > When a package is requested (either on command line or as a dependency) portage > chooses the latest version that is not masked, and tries to satisfy > dependencies for that. If that fails it explains why the dependencies for that > particular version cannot be satisfied. It is fine as long as installing this > particular version is the right thing. > However, portage does not (afaict) provide any diagnostics wether the choice > portage did for me was right to start with. There might be a lower version of > the package for wich the dependencies are already satisfied or a higher version > of the package that is still masked. The only choice portage makes at the moment is "the highest unmarked version satisfying a given atom". That is the only choice portage makes. It could theoretically make other choices in order to build a valid dep graph with what packages are available but does not yet have that capability coded into it. > I do not know how to find out. > Sure I can read all the involved ebuilds myself. If I can find out which are > involved. How to find out is by reading ebuilds. How to find out which are involved is by looking at the diagnostic message that emerge gave you and then manually tracing out dependencies by reading ebuilds. > But why do we have portage then? We can also run ebuilds manually. Managing your whole system with only using the "ebuild" command (which uses portage - are you referring to "emerge" here?) is a valid choice that is yours to make. Amazingly enough, I don't think there is an existing bug that covers merging not-the-latest-version of a package in order to make a complete dep graph. Shame that this one has to be it... (In reply to comment #24) > Lot of heated "discussion" here, eh? ;) > > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #15) > > > > Why does it report ay errors at all then? The depgraph should not be broken if > > > > you do things properly :P > > > > > > Huh? _You_ have broken the depgraph by masking stuff improperly/not unmasking > > > it properly. Or, a broken ebuild has broken the depgraph because it's not > > > ported for modular X. What does portage have in common with this? > > > > Oh so you propose that portage is already way too verbose, and that any > > dependency problem should be reported this way: "Your dependency graph is > > broken. Fix it." ? > > Portage already gives as much information as it reasonably can. What I am telling all the time is that it does not. There are packages a and b. a-0 requires at least b-0, a-1 requires at least b-1, and a-2 requires c. a-2 and b-1 is masked. If you want to install _some_ a, portage defaults to highest unmasked version, and that is a-1. It then tries to resolve the dependency on b. Only b-1 falls into the possible range, and portage says that b-1 is masked. However, it does not say that the dependency of a-0 is not masked, nor is the dependency of a-2. It is reasonably possible to report that. The information portage reports is asymmetrical. It goes to great detail about b but it only says which version of a it picked. > The only choice portage makes at the moment is "the highest unmarked version > satisfying a given atom". That is the only choice portage makes. It could > theoretically make other choices in order to build a valid dep graph with what > packages are available but does not yet have that capability coded into it. yes. Portage was designed that way. I am not saying it is wrong. I am just saying that it is completely reasonable to inform the user that a different version of the package is available, especially if dependencies for the different version can be satisfied. > > > I do not know how to find out. > > Sure I can read all the involved ebuilds myself. If I can find out which are > > involved. > > How to find out is by reading ebuilds. How to find out which are involved is by > looking at the diagnostic message that emerge gave you and then manually > tracing out dependencies by reading ebuilds. I got the idea that emerge is for tracing dependencies. > > > But why do we have portage then? We can also run ebuilds manually. > > Managing your whole system with only using the "ebuild" command (which uses > portage - are you referring to "emerge" here?) is a valid choice that is yours > to make. Yes, I meant emerge here. > > > Amazingly enough, I don't think there is an existing bug that covers merging > not-the-latest-version of a package in order to make a complete dep graph. > Shame that this one has to be it... It might be a nice feature. Debian has that. But they are also plagued by resolver bugs. Please, stop messing w/ components and severity of this bug, thanks. Automatic unmasking of packages including dependencies completely defeats the purpose of unstable keywords. If you can't cope w/ that, run stable. You can also run all unstable and save yourself the hassle as well. (In reply to comment #24) > Lot of heated "discussion" here, eh? ;) > > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #15) > > > > Why does it report ay errors at all then? The depgraph should not be broken if > > > > you do things properly :P > > > > > > Huh? _You_ have broken the depgraph by masking stuff improperly/not unmasking > > > it properly. Or, a broken ebuild has broken the depgraph because it's not > > > ported for modular X. What does portage have in common with this? > > > > Oh so you propose that portage is already way too verbose, and that any > > dependency problem should be reported this way: "Your dependency graph is > > broken. Fix it." ? > > Portage already gives as much information as it reasonably can. What I am telling all the time is that it does not. There are packages a and b. a-0 requires at least b-0, a-1 requires at least b-1, and a-2 requires c. a-2 and b-1 is masked. If you want to install _some_ a, portage defaults to highest unmasked version, and that is a-1. It then tries to resolve the dependency on b. Only b-1 falls into the possible range, and portage says that b-1 is masked. However, it does not say that the dependency of a-0 is not masked, nor is the dependency of a-2. It is reasonably possible to report that. The information portage reports is asymmetrical. It goes to great detail about b but it only says which version of a it picked. > The only choice portage makes at the moment is "the highest unmarked version > satisfying a given atom". That is the only choice portage makes. It could > theoretically make other choices in order to build a valid dep graph with what > packages are available but does not yet have that capability coded into it. yes. Portage was designed that way. I am not saying it is wrong. I am just saying that it is completely reasonable to inform the user that a different version of the package is available, especially if dependencies for the different version can be satisfied. > > > I do not know how to find out. > > Sure I can read all the involved ebuilds myself. If I can find out which are > > involved. > > How to find out is by reading ebuilds. How to find out which are involved is by > looking at the diagnostic message that emerge gave you and then manually > tracing out dependencies by reading ebuilds. I got the idea that emerge is for tracing dependencies. > > > But why do we have portage then? We can also run ebuilds manually. > > Managing your whole system with only using the "ebuild" command (which uses > portage - are you referring to "emerge" here?) is a valid choice that is yours > to make. Yes, I meant emerge here. > > > Amazingly enough, I don't think there is an existing bug that covers merging > not-the-latest-version of a package in order to make a complete dep graph. > Shame that this one has to be it... It might be a nice feature. Debian has that. But they are also plagued by resolver bugs. (In reply to comment #26) > > Automatic unmasking of packages including dependencies completely defeats the > purpose of unstable keywords. If you can't cope w/ that, run stable. You can > also run all unstable and save yourself the hassle as well. I was not requesting that. This was about emerge telling what could be masked/unmasked to resolve the dependencies. And no, it does not defeat the purpose of unstable keywords. If you want an unstable package, there is nothing wrong with having a tool that tells you what needs to be unmasked to install it, and adds the packages to package.keywords much like emerge -a lets you review what is going to be installed. an idea. I would like some kind of auto unmask dependancies. It's a pain unmasking all of kde or xorg. perhaps portage could have a feature where it would insert lines into example package.keywords. or if thats a directory into say x11-drivers for a file that comes from that. note: I assume that works. have it prompt all ebuilds satisfying * are masked. would you like to unmask? Yes/no this would make unmasking multiple dependancies easier however still make it so you know what you are doing. Afaik, it's been portage team policy for years to not implement the automatic unmasking of dependencies. If you are looking to unmask xorg, following the guide provides simple steps to getting the packages unmasked. (In reply to comment #27) > (In reply to comment #24) > > Portage already gives as much information as it reasonably can. > > What I am telling all the time is that it does not. > <snipped example> > > > The only choice portage makes at the moment is "the highest unmarked version > > satisfying a given atom". That is the only choice portage makes. It could > > theoretically make other choices in order to build a valid dep graph with what > > packages are available but does not yet have that capability coded into it. > > yes. Portage was designed that way. I am not saying it is wrong. I am just > saying that it is completely reasonable to inform the user that a different > version of the package is available, especially if dependencies for the > different version can be satisfied. If emerge was able to give that information, it could just as easily fully resolve the dep graph using alternate packages. If you want to see all versions that are available of every package that is checked, use --debug and you will get it. If you want emerge to figure out which package is causing the dep graph to fail and show you alternate possibilities, it will never happen. Once we can get emerge to figure out which package(s) is/are causing the dep graph to fail, we'll move straight on to automatically selecting alternate packages. > > > I do not know how to find out. > > > Sure I can read all the involved ebuilds myself. If I can find out which are > > > involved. > > > > How to find out is by reading ebuilds. How to find out which are involved is by > > looking at the diagnostic message that emerge gave you and then manually > > tracing out dependencies by reading ebuilds. > > I got the idea that emerge is for tracing dependencies. Which is what emerge does. It's not perfect though as stated above. When you mask packages on your system in a way that emerge is unable to handle, it is up to you to figure out why and fix it. > > Amazingly enough, I don't think there is an existing bug that covers merging > > not-the-latest-version of a package in order to make a complete dep graph. > > Shame that this one has to be it... > > It might be a nice feature. Debian has that. But they are also plagued by > resolver bugs. This bug is still open is it not? That indicates that we hope to one day support these cases. > (In reply to comment #26) > > > > Automatic unmasking of packages including dependencies completely defeats the > > purpose of unstable keywords. If you can't cope w/ that, run stable. You can > > also run all unstable and save yourself the hassle as well. > > I was not requesting that. This was about emerge telling what could be > masked/unmasked to resolve the dependencies. Emerge already does that. !!! All ebuilds that could satisfy ">=dev-libs/glib-2.5.7" have been masked. !!! One of the following masked packages is required to complete your request: - dev-libs/glib-2.8.6 (masked by: package.mask) - dev-libs/glib-2.8.5 (masked by: package.mask) - dev-libs/glib-2.8.4 (masked by: package.mask) - dev-libs/glib-2.6.5 (masked by: package.mask) - dev-libs/glib-2.10.3 (masked by: package.mask) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "dev-libs/atk-1.11.4" [ebuild]) dev-libs/atk-1.11.4 requires >=dev-libs/glib-2.5.7 and the possibilities are glib 2.6.5, 2.8.4, 2.8.5, 2.8.6 and 2.10.3. If you are asking for emerge to continue on and give you a complete list of what needs to be unmasked in one go, then it will never happen. What you are asking for is that emerge second guesses you and arbitrarily chooses one of the packages from the above list before going on to see if anything else is masked. In other words, if you want emerge to find out what needs to be unmasked in order to build a complete dep graph, it will never happen. If you want emerge to examine packages other than that which is the latest available in order to build a complete dep graph in the case where the latest available packages cannot be used, it will eventually happen. It seems this bug is not still open anymore. Either way, my last comment still applies. Would you like resolve LATER instead? :) (In reply to comment #26) > Please, stop messing w/ components and severity of this bug, thanks. > Sorry, I was not aware of that. Must have been field values cached in the browser. OK, I tried to explain at least three times. And I am quite positive I did _not_ write the explanation in Chinese. It appears the concept that there are actually two packages involved in a dependency relationship is completely alien to gentoo users and developers. I always wondered why portage seems to be very advanced in some respects yet from other points of view it may still appear deep in the stone age. Now I know. It is an alien design. It is not the issue who is the alien here. I just need to find a distro that resides somewhere near enough the world in which I live so that I can communicate with the users and developers of the distro. As the classic says: Goodbye, and thanks for all the fishies :) (In reply to comment #33) > It appears the concept that there are actually two packages involved in a > dependency relationship is completely alien to gentoo users and developers. For anybody who wants to follow up on actual coding for this bug, the broader issue is that the amount of packages involved in the dependency relationship can extend from two packages right the way through to every package in the graph. (In reply to comment #34) > (In reply to comment #33) > > It appears the concept that there are actually two packages involved in a > > dependency relationship is completely alien to gentoo users and developers. > > For anybody who wants to follow up on actual coding for this bug, the broader > issue is that the amount of packages involved in the dependency relationship > can extend from two packages right the way through to every package in the > graph. > How can it? There is only partial graph that cannot be completed, and emerge reports the place where it broke. That is exactly between two particular packages. I wanted more information about this place than emerge currently reports because for me such information would be helpful and make using of emerge easier. I thought other gentoo users could also find the information helpful so I filed a bug about that. Since it looks like nobody else here is able to understand the concept implementing such feature would be indeed pointless. (In reply to comment #35) > (In reply to comment #34) > > For anybody who wants to follow up on actual coding for this bug, the broader > > issue is that the amount of packages involved in the dependency relationship > > can extend from two packages right the way through to every package in the > > graph. > > > > How can it? There is only partial graph that cannot be completed, and emerge > reports the place where it broke. That is exactly between two particular > packages. The parent package and the child atom which cannot be resolved to an unmasked child package... > I wanted more information about this place than emerge currently reports > because for me such information would be helpful and make using of emerge > easier. I thought other gentoo users could also find the information helpful so > I filed a bug about that. I came to this bug late so I may have missed it through all the arguing and sarcasm, but what exactly do you want? When there is a child atom that cannot be resolved to a child package, you want to know what atom brought the parent package in and what other possible packages might satisfy that atom? > Since it looks like nobody else here is able to understand the concept > implementing such feature would be indeed pointless. More sarcasm and arguing... If you ignore Jakub's sarcasm and arguing, you've brought this bug to the state that it's in. (In reply to comment #36) > (In reply to comment #35) > > (In reply to comment #34) > > > For anybody who wants to follow up on actual coding for this bug, the broader > > > issue is that the amount of packages involved in the dependency relationship > > > can extend from two packages right the way through to every package in the > > > graph. > > > > > > > How can it? There is only partial graph that cannot be completed, and emerge > > reports the place where it broke. That is exactly between two particular > > packages. > > The parent package and the child atom which cannot be resolved to an unmasked > child package... > > > I wanted more information about this place than emerge currently reports > > because for me such information would be helpful and make using of emerge > > easier. I thought other gentoo users could also find the information helpful so > > I filed a bug about that. > > I came to this bug late so I may have missed it through all the arguing and > sarcasm, but what exactly do you want? When there is a child atom that cannot > be resolved to a child package, you want to know what atom brought the parent > package in and what other possible packages might satisfy that atom? yes, that's it. > > > Since it looks like nobody else here is able to understand the concept > > implementing such feature would be indeed pointless. > > More sarcasm and arguing... If you ignore Jakub's sarcasm and arguing, you've > brought this bug to the state that it's in. > Indeed, if I ignored what Jakub said there are only three more people that missed the point. But at least they did not give such useful suggestions like "If your dependecy graph is broken you have to fix it. Portage has nothing to do with that." OK, perhaps I gave up too early. Third try: The description of the issue is in comment #36, and the start of comment #27. (In reply to comment #38) > OK, perhaps I gave up too early. > > Third try: > > The description of the issue is in comment #36, and the start of comment #27. > All right, enough. Stop recycling this bug endlessly, changing it's summary to something completely different over and over again every time it's been closed. It's confusing like hell and a complete mess. (In reply to comment #39) > All right, enough. Stop recycling this bug endlessly, changing it's summary to > something completely different over and over again every time it's been closed. > It's confusing like hell and a complete mess. > No, this was what this was about in the first place. I wonder why people change it to something else ;-) the scenario mentioned in comment #27 is a valid bug. I'd reopen this bug, if it wasn't so messy, but i thought it was better to open bug 137562 And - this is *exactly* why bugzilla sucks big time for _generic_ suggestions and discussions. What would be really great is - having a discussion on gentoo-portage-dev mailing first (if it becomes a mess, you can start a new thread at the point the topic has moved to something completely different) and once you've sorted out all of this and get to some conclusions where's the problem, what would be nice to have and how it should be done, then file a really *specific* bug about that one particular thing. Starting a bug at the point where you don't even know what the issue is and asking for portage changes of an unspecified and unclear nature is bound to be a big mess. (In reply to comment #41) > the scenario mentioned in comment #27 is a valid bug. I'd reopen this bug, if > it wasn't so messy, but i thought it was better to open bug 137562 > That is what I tried with bug #137564 but you apparently got there earlier :) Jakub: while I appreciate your work as bug-wrangler, once you've assigned a bug to a team leave it up to the team to handle the bug. Input is of course welcome, but try to avoid changing the status without consulting the team first. |
