Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 136638 - automatically unmask a package and it's dependencies
Summary: automatically unmask a package and it's dependencies
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 136641 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-13 04:15 UTC by Michal Suchanek
Modified: 2006-06-22 07:45 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Suchanek 2006-06-13 04:15:15 UTC
One example:
There is a package that wants virtual/xft.
I have masked <virtual/xorg-7.0 to disable installation of non-modular xorg.
There is a package virtual/xft-6.8, and virtual/xft - some later version, masked by ~x86.
virtual/xft-6.8 depends on <=xorg-6.99.something.

I emerge world. Portage tells me that all versions of xorg satisfying <=xorg-6.99.something are masked, and that it is a dependency of virtual/xft.

equery gives me a half dozen of packages that depend on virtual/xft. They are quite new so it is apparently not an outdated dependency.

Now what?

Portage does not allow searching for virtual packages. Even if it did, it does not return masked packages. So how do I tell that I should keyword virtual/xft unless somebody who knows about the package tells me?
Comment 1 solar (RETIRED) gentoo-dev 2006-06-13 04:47:13 UTC
*** Bug 136641 has been marked as a duplicate of this bug. ***
Comment 2 Zac Medico gentoo-dev 2006-06-13 06:46:31 UTC
Please post the exact command and it's output.
Comment 3 Zac Medico gentoo-dev 2006-06-13 06:48:29 UTC
Also, please attach the output of `emerge --info`.
Comment 4 Michal Suchanek 2006-06-13 08:00:46 UTC
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
Comment 5 Zac Medico gentoo-dev 2006-06-13 13:31:42 UTC
(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?
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2006-06-14 05:41:18 UTC
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.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2006-06-14 05:53:34 UTC
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.
Comment 8 Eric Anderson 2006-06-14 13:34:40 UTC
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
Comment 9 Zac Medico gentoo-dev 2006-06-14 13:48:29 UTC
(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?
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2006-06-14 13:55:28 UTC
(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. :)
Comment 11 Zac Medico gentoo-dev 2006-06-14 14:08:39 UTC
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...
Comment 12 Michal Suchanek 2006-06-16 00:34:37 UTC
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.
Comment 13 Michal Suchanek 2006-06-16 00:36:09 UTC
Resetting the summary. This is not about pulling the wrong package.
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2006-06-16 00:54:41 UTC
(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.
Comment 15 Michal Suchanek 2006-06-16 02:25:52 UTC
(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. 

Comment 16 Michal Suchanek 2006-06-16 02:38:22 UTC
(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.
Comment 17 Jakub Moc (RETIRED) gentoo-dev 2006-06-16 03:56:44 UTC
(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. ;)
Comment 18 Michal Suchanek 2006-06-16 05:11:37 UTC
(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.

Comment 19 Jakub Moc (RETIRED) gentoo-dev 2006-06-16 05:28:13 UTC

*** This bug has been marked as a duplicate of 79606 ***
Comment 20 Michal Suchanek 2006-06-16 06:45:06 UTC
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.
Comment 21 Zac Medico gentoo-dev 2006-06-16 08:14:52 UTC
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.
Comment 22 Michal Suchanek 2006-06-16 08:50:30 UTC
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.
Comment 23 Zac Medico gentoo-dev 2006-06-16 09:23:42 UTC
(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
Comment 24 Jason Stubbs (RETIRED) gentoo-dev 2006-06-16 09:24:23 UTC
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...
Comment 25 Michal Suchanek 2006-06-17 11:59:47 UTC
(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. 

Comment 26 Jakub Moc (RETIRED) gentoo-dev 2006-06-17 12:44:03 UTC
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.
Comment 27 Michal Suchanek 2006-06-17 13:50:28 UTC
(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. 

Comment 28 Caleb Cushing 2006-06-17 18:12:50 UTC
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.
Comment 29 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-06-17 18:35:18 UTC
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.
Comment 30 Jason Stubbs (RETIRED) gentoo-dev 2006-06-17 20:12:14 UTC
(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.
Comment 31 Jason Stubbs (RETIRED) gentoo-dev 2006-06-17 20:13:03 UTC
It seems this bug is not still open anymore. Either way, my last comment still applies.
Comment 32 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-06-17 21:14:51 UTC
Would you like resolve LATER instead? :)
Comment 33 Michal Suchanek 2006-06-18 03:25:36 UTC
(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 :)

Comment 34 Jason Stubbs (RETIRED) gentoo-dev 2006-06-18 22:26:06 UTC
(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.
Comment 35 Michal Suchanek 2006-06-19 06:37:08 UTC
(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.
Comment 36 Jason Stubbs (RETIRED) gentoo-dev 2006-06-19 09:05:46 UTC
(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.
Comment 37 Michal Suchanek 2006-06-19 14:50:35 UTC
(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."
Comment 38 Michal Suchanek 2006-06-22 04:13:03 UTC
OK, perhaps I gave up too early.

Third try:

The description of the issue is in comment #36, and the start of comment #27.

Comment 39 Jakub Moc (RETIRED) gentoo-dev 2006-06-22 04:17:37 UTC
(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.
Comment 40 Michal Suchanek 2006-06-22 04:42:09 UTC
(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 ;-)
Comment 41 Simon Stelling (RETIRED) gentoo-dev 2006-06-22 04:45:01 UTC
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
Comment 42 Jakub Moc (RETIRED) gentoo-dev 2006-06-22 04:51:47 UTC
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.
Comment 43 Michal Suchanek 2006-06-22 05:01:35 UTC
(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 :)
Comment 44 Marius Mauch (RETIRED) gentoo-dev 2006-06-22 07:45:12 UTC
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.