When I tried to install media-gfx/uniconvertor with 'cave' (from Paludis) I stumbled upon a weird dependency in the media-libs/sk1libs-0.9.1 Ebuild: [...] DEPEND=" media-libs/freetype:2 virtual/jpeg =media-libs/lcms-1* >=media-libs/lcms-1.15[python]" [...] As far as I understand it, instead of depending on media-libs/lcms twice, one slot dependency should suffice: [...] DEPEND=" media-libs/freetype:2 virtual/jpeg >=media-libs/lcms-1.15:0[python]" [...] Here is the corresponding Paludis bug with a lot more information and a detailed description of the problem: http://trac.pioto.org/paludis/ticket/1096 Thanks a lot.
I think the meaning of the old DEPEND is to either require =media-libs/lcms-1* or >=media-libs/lcms-1.15[python] and not both at once. So I would think this is what you meant: Index: sk1libs-0.9.1.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/media-libs/sk1libs/sk1libs-0.9.1.ebuild,v retrieving revision 1.4 diff -u -B -r1.4 sk1libs-0.9.1.ebuild --- sk1libs-0.9.1.ebuild 9 Nov 2010 15:21:53 -0000 1.4 +++ sk1libs-0.9.1.ebuild 31 Jan 2011 05:12:48 -0000 @@ -22,8 +22,7 @@ DEPEND=" media-libs/freetype:2 virtual/jpeg - =media-libs/lcms-1* - >=media-libs/lcms-1.15[python]" + || ( >=media-libs/lcms-1.15[python] =media-libs/lcms-1* )" RDEPEND="${DEPEND} app-text/ghostscript-gpl media-libs/netpbm"
The ebuild is correct: =media-libs/lcms-1.19 with USE=python will satisfy both of: =media-libs/lcms-1* And: >=media-libs/lcms-1.15[python] If the package manager bails on because of it, it's broken
(In reply to comment #2) > The ebuild is correct: Your assumption of correct is based on what? Is it "Portage is correct." or is there any detailed documentation on expected behaviour or semantics in a Gentoo package manager? I have looked through the Gentoo documentation http://www.gentoo.org/doc/en/) and thus far came up with nothing. I would be glad about a hint where I can find the correct interpretation of an ebuild, so I won't file any false positives in the future. (In reply to comment #1) > + || ( >=media-libs/lcms-1.15[python] =media-libs/lcms-1* )" This comes pretty close to my interpretation, but the funny thing is media-libs/lcms:2 does not have a "python" USE flag anymore. That's why || ( >=media-libs/lcms-1.15 =media-libs/lcms-1*[python] )" or my earlier proposal would make a lot more sense to me. But I believe the python-bindings aren't a part of lcms in version 2. So the || dependency is possibly wrong. Concerning ebuild semantic documentation, the only thing I found was http://devmanual.gentoo.org/general-concepts/dependencies/index.html and 'man 5 ebuild' and this leaves too much room for interperation. So here is mine: I look at dependency =media-libs/lcms-1* and come up with possibility media-libs/lcms-1.19 which satisfies the dependency. Now I look at dependency >=media-libs/lcms-1.15[python] and come up with media-libs/lcms-2.0a but this can not satisfy the "python" USE flag. So I would have to resort to an older package (media-libs/lcms-1.19). But then my proposed dependency is the more specific approach to describe this dependency: >=media-libs/lcms-1.15:0[python] And is it usually not better to be more specific than to be ambivalent when describing dependencies? Especially when the possible solutions you include by ambivalence are no solutions in the end? What is the rationalization for being more unspecific? Hope you can help me understand. Thanks for your time and patience.
>=media-libs/lcms-1.15:0[python] could be used, but there's no point in fixing the package if an unofficial package manager is broken: sk1libs needs lcms-1 at least version 1.15 with USE=python, the deps no way refers to lcms-2 at all. portage gets this right. || ( ) is not related at all here. =media-libs/lcms-1* --> make sure lcms from =1* range gets pulled >=media-libs/lcms-1.15[python] --> make sure it's at least version 1.15 and with USE=python and with both those combined, you get correct depend.
... because >=media-libs/lcms-1.15[python] should pick the newest version that has USE="python" and in this case, it's 1.19.
What is solution for this then, paludis bug states this is ebuild problem and bug should be filled upstream (this bug), but this bug states there is no point in changing ebuild because of unofficial package manager because it works with portage... I will move ebuild to local overlay and change it there but seems like bug sort of circle in never ending loop...
(In reply to comment #6) > I will move ebuild to local overlay and change it there but seems like bug sort > of circle in never ending loop... I did the same, because I had the feeling the problem is not the bug, but politics. But too be honest: I did not have the time to investigate and decide for myself if there is any long-term advantage in one of the two ways (portage vs. paludis) those double dependencies are handled. It just seemed to me like the simpler way to change the ebuild to be compatible with both interpretations of a double dependency, instead of arguing about which one is wrong and which one is right.
Since media-libs/lcms is slotted, wouldn't it be more reasonable specifying media-libs/lcms:0[python] instead this mixed double? I don't want to argue about paludis being broken here, since I'm not familiar enough with the depspec at this point, but I just wondered why anyone would express things in such a… scary way anyway.
Hi, this case is similar to one I had with vlc a few weeks ago. Please see bug 348518 as well as the lengthy discussion that followed on the gentoo-dev mailing list. http://archives.gentoo.org/gentoo-dev/msg_6977c4c839e3ff3356d159cbe0c173cd.xml If I'm not mistaking the dependency should be specified something like : || ( >=media-libs/lcms-2.0 <media-libs/lcms-2.0[python] )
(In reply to comment #9) > If I'm not mistaking the dependency should be specified something like : > > || ( >=media-libs/lcms-2.0 <media-libs/lcms-2.0[python] ) Since media-libs/lcms-2.x seems to have no python bindings anymore this would probably not work.
Yes it would. Please follow the links I have pasted. In the vlc ebuild now there is the following dependency : opengl? ( virtual/opengl || ( >=x11-libs/libX11-1.3.99.901 <x11-libs/libX11-1.3.99.901[xcb] ) ) which is there because <x11-libs/libX11-1.3.99.901 has a xcb use flag while >=x11-libs/libX11-1.3.99.901 does not. Notice the ordering too : the most recent version must be left most.
(In reply to comment #11) > Notice the ordering too : the most recent version must be left most. I think I've got your point last time. If I was unclear: Your proposal would work if there were any Python bindings, but if >=media-libs/lcms-2.0 is used there are no Python bindings at all. It is not just the USE-flag which is gone, the whole Python support/API is gone in newer versions. I assume media-libs/sk1libs would stop working similar to this: http://sk1project.org/forum_old/topic.php?forum=1&topic=48
Right ! But I think it's a different point :-) My point is that right now, the ebuild has an invalid dependency which makes paludis fail. It's not a syntax error, but it's almost the same class of issue. Your point is that sk1libs may not work with lcms>=2.0 because of a missing feature. I understand your point. However nothing prevents you from fixing the ebuild dependency first, and then eventually handle the python-bindings issue if really needed. And probably only upstreams could inform you of the correct way to go.
The funny bit (0|1) seems to be that paludis isn't getting fixed.
AFAICT This is not a bug in paludis : paludis just has a different heuristic that assumes dependencies are defined "best thing left most" which is the officially recommended way (although not specified in PMS) for defining this kind of dependency. See the link I pasted in comment #9. It's when the dependency is not "best things left most", that portage and paludis behave differently. And in this case, the behavior of the package manager is completely unspecified. So we cannot say it is a paludis bug. Notice I'm not a PM specialist : it's just what I understood of the discussion that happened on the gentoo-dev ML.
It is really frustrating to not see this trivial one liner fix in. Honestly I do not understand your reluctance.
I don't see how this is not a paludis bug. The spec "A B" asks for the intersection of the package sets provided by the restrictions A and B. The spec =media-libs/lcms-1* requires an lcms with major version of 1. The spec >=media-libs/lcms-1.15[python] requires any lcms version greater or equal than 1.15 with the python use flag enabled. So you need lcms with the python use flag, and 1.15 <= version < 2. And the tree has 1.19 available or installed.
(In reply to comment #17) BTW I was only talking about the case in which A and B are different versions of the same package. It makes no sense otherwise.
@cJ: i'm not the PM expert, look at the discussion on gentoo-dev (link at comment #9)
(In reply to comment #18) > (In reply to comment #17) > BTW I was only talking about the case in which A and B are different versions > of the same package. > It makes no sense otherwise. It was pretty naive to me to say that. As it was explained to me, the dependency list specs are independant. What I said before would not enable the following dep list : ruby_targets_ruby18? ( dev-lang/ruby:1.8 ) ruby_targets_ruby19? ( dev-lang/ruby:1.9 )
(In reply to comment #20) > ruby_targets_ruby18? ( dev-lang/ruby:1.8 ) ruby_targets_ruby19? ( > dev-lang/ruby:1.9 ) Damned keyboard, I sent my comment without having finished to type, sorry. If you go to /usr/portage/metadata/cache and run : find | while read file; do head -n 1 $file | egrep '(.*\/.*):.*\1' ; done you'll see that all dependency lists requesting multiple versions of the same package need them all installed, such as the above example Now I'm trying to understand the second part of the issue, ie. why cave complains about a version when another could be installed.
(In reply to comment #21) > Now I'm trying to understand the second part of the issue, ie. why cave > complains about a version when another could be installed. Failed. Invoking our QA overlords.
Paludis is right. The dep is wrong. You need to bear in mind: * Dependencies apply *individually*. ( =foo-1 =foo-2 ) means "I need something matching =foo-1" and "I need something matching =foo-2", not "I need something matching =foo=1 and =foo-2" * [use] dependencies don't restrict to versions. It's illegal to apply a [use] dependency to any version without first ensuring that the rest of the spec's requirements restrict potential matches to only things that could have that flag. Thus, the ">=media-libs/lcms-1.15[python]", which is considered entirely independently of the =1* requirement, gets applied to both slots.
+ 27 Mar 2011; Samuli Suominen <ssuominen@gentoo.org> sk1libs-0.9.1.ebuild: + Workaround broken package managers (sys-apps/paludis) wrt #353051. The bug should stay open until paludis is fixed to handle dependencies as it should.
Or PMS is fixed to disallow depend.
You have to sattisfy each individual dep but given that there is NO restriction in naming each dep multiple times with different options it is not sufficient. So in theory you should to create set where you do conjunction of all statements from it. But given that this is not named in PMS anywhere i guess it is up to the PM implementation itself if it decides to implement it and how. So we should just alter the dep for now. Never the less key factor for this is support in portage where it determines whats "right" for main tree if it does not have PMS specification nor contradict some. So the dependency is correct just not supported (or planned to be supported) by paludis.
The way Paludis treats it is correct, and the dependency you had is explicitly illegal under PMS. Handling things the way you appear to want them to be handled would break packages that depend upon multiple slots of another package. Please learn the basics of how dependencies work before attempting to argue with the spec.
Closing this off as INVALID as per previous explanations.
So can we close this?
On Friday, December 19, 2014 02:59:58 PM you wrote: > --- Comment #29 from Julian Ospald (hasufell) <hasufell@gentoo.org> --- > So can we close this? TL;DR: From my point of view: Yes ... and hereby done. To be clear: The current summary does not represent the original intent I had when creating this bug, the original summary line was: | media-libs/sk1libs-0.9.1: double dependencies on media-libs/lcms instead of | one single slot dependency This report went from -- what I thought was -- a two liner bug fix to some sort of a debate about which package manager is right. Since my original problem was solved -- even when not accepted as an actual bug -- by Samuli (a big "thank you" for that :), I could close it. I just kept it open because he stated: > The bug should stay open until paludis is fixed to handle dependencies as it > should. But as the main developer of Paludis previously stated: Paludis behaviour won't be changed in that regard. So, I agree, the best short term solution is probably to close this bug. I just thought from the last comment of Ciaran, that this was already done. To be clear, I still think the package dependency was malformed in the first place: I don't see the need for the package manager to handle two dependency lines, which can be expressed in one line, having the same effect and being semantically more precise. I personally am a bit torn between arguments. For example, I don't see the paragraph in the PMS where it is explicitly forbidden to select a version from one slot by more than one spec line. But, asthetically I prefer the one-liner; it's one line and it says it all. And I suppose the logic being implemented by the dependency resolver is simpler than when merging multiple separate lines and trying to guess to which slot each line actually belongs. I think the assumption Paludis makes, that ">=media-libs/lcms-1.15[python]" selects any package greater than or equal to 1.15 regardless of the slot and matches USE flags later is valid -- meaning: the PMS does not specify otherwise. How I understand the "Portage interpretation", this would be an equivalent and valid package specification, too: media-libs/lcms[python] >=media-libs/lcms-1.15 <media-libs/lcms-2 But, who would want that? So, I am all for being as precise as possible in the package dependency specification: One slot, one line.
There's another incarnation of this bug I believe is still in the tree: dev-ruby/rake ---- ruby_targets_ruby19? ( virtual/rubygems[ruby_targets_ruby19] ) ruby_targets_ruby20? ( virtual/rubygems[ruby_targets_ruby20] ) ruby_targets_ruby21? ( virtual/rubygems[ruby_targets_ruby21] ) ruby_targets_ruby22? ( virtual/rubygems[ruby_targets_ruby22] ) ---- Paludis gets stuck attempting to install only the latest slot, and then saying its bad because it misses useflags: Did not meet virtual/rubygems[ruby_targets_ruby19], use existing if possible, installing to / from dev-ruby/rake-10.4.2:0::gentoo Flag 'ruby_targets_ruby19' enabled Did not meet virtual/rubygems[ruby_targets_ruby20], use existing if possible, installing to / from dev-ruby/rake-10.4.2:0::gentoo Flag 'ruby_targets_ruby20' enabled Did not meet virtual/rubygems[ruby_targets_ruby21], use existing if possible, installing to / from dev-ruby/rake-10.4.2:0::gentoo Flag 'ruby_targets_ruby21' enable If you feel this bug is independent from that one ( I don't think it is reading http://paludis.exherbo.org/trac/ticket/1096 ), I might file a "fix rubygems virtuals" bug, but I expect it will become a reiteration of this bug arguing the package manager is wrong, etc.
(In reply to Kent Fredric from comment #31) > If you feel this bug is independent from that one ( I don't think it is > reading http://paludis.exherbo.org/trac/ticket/1096 ), I might file a "fix > rubygems virtuals" bug, but I expect it will become a reiteration of this > bug arguing the package manager is wrong, etc. You are in luck this issue was already reported: https://bugs.gentoo.org/show_bug.cgi?id=421497 You might wanna add your vote there. :) I thought for a moment if this report should stay open until the PMS is changed as Samuli stated in Comment #25 -- but then again: my original intent was to fix "media-libs/sk1libs" and I somehow doubt that this bug being open would help with changing the PMS. I think there should be a dedicated bug report regarding a PMS change. Or at least a bug report concerning a problem which cannot be fixed by simplifying the ebuild's dependencies. #421497 might be that bug report. I agree the symptoms are very similar. Both problems might be even fixed by the same change to the PMS). But the origin (fixable malformed dependency vs. hackish portage-specific workaround) and possibly the solutions of the problems are different.
