Hi, it looks like the libX11 dependency described in vlc-1.1.5 is wrong. paludis says : ! x11-libs/libX11 Reasons: target (installed-packages::installed), app-emulation/emul-linux-x86-xlibs, dev-dotnet/libgdiplus, 126 more Unsuitable candidates: * x11-libs/libX11-1.3.4:0::gentoo Did not meet >=x11-libs/libX11-1.3.99.901, use existing if possible, installing to / from media-libs/mesa * x11-libs/libX11-1.3.6:0::gentoo Did not meet >=x11-libs/libX11-1.3.99.901, use existing if possible, installing to / from media-libs/mesa * x11-libs/libX11-1.4.0:0::gentoo Did not meet <x11-libs/libX11-1.4.0[xcb], use existing if possible, installing to / from media-sound/pulseaudio Did not meet <x11-libs/libX11-1.3.99.901[xcb], use existing if possible, installing to / from media-video/vlc * x11-libs/libX11-9999:0::x11 Masked by repository Repository masked /var/paludis/repositories/x11/profiles/package.mask Don't let people install these accidentally Masked by user Did not meet <x11-libs/libX11-1.4.0[xcb], use existing if possible, installing to / from media-sound/pulseaudio Did not meet <x11-libs/libX11-1.3.99.901[xcb], use existing if possible, installing to / from media-video/vlc Looking at the vlc-1.1.5 ebuild I see : opengl? ( virtual/opengl || ( <x11-libs/libX11-1.3.99.901[xcb] >=x11-libs/libX11-1.3.99.901 ) ) which, according to Ciaran, is wrong because || ( a b ) means "prefer a, but b is fine too". Reproducible: Always paludis-0.56
I'm not used to paludis output, but can it be it complains about xcb useflag not set on <libX11-1.4.0 ?
(In reply to comment #1) > I'm not used to paludis output, but can it be it complains about xcb useflag > not set on <libX11-1.4.0 ? Yes libX11<1.4.0 has the xcb useflag, libX11>=1.4.0 has not. The author of paludis says that the way this dependency is defined in the ebuild is wrong : || ( a b ) means "prefer a, but b is fine too" I tried that one but it's real syntax error : opengl? ( virtual/opengl || ( <x11-libs/libX11-1.3.99.901[xcb] || >=x11-libs/libX11-1.3.99.901 ) ) I don't know the solution :-(
If you've got || ( a b c ) then the best solution is supposed to be listed first. In particular, if you've got || ( >cat/a-1 <cat/a-1 ) then the > should always be to the left of the < thing. Otherwise, you're telling the package manager that it should prefer the older version.
At first sight, PMS-3 pages 31 and 32 don't tell anything of the proposed "preference" in any-of "|| ( ... )" groups. Flipping back to the documents titlepage arises the questions: Why isn't it documented?
So ? Is it possible to update the vlc ebuild dependency ? Or should I put the item on the gentoo-dev mailing list so that all PMS experts can debate ?
(In reply to comment #4) > At first sight, PMS-3 pages 31 and 32 don't tell anything of the proposed > "preference" in any-of "|| ( ... )" groups. > > Flipping back to the documents titlepage arises the questions: Why isn't it > documented? It's documented in ebuild(5): Here only one of the packages will be chosen, and the order of preference is determined by the order in which they appear. Of course, you should be wary of anything in there, since the second example it gives for || ( ) dependencies is impossible to implement correctly... It's not in PMS because the exact selection algorithm tends to be heavily package manager dependent, and no-one's figured out a sufficiently flexible way of expressing that. However, the "best left" thing is universal.
Come on guys ! It's one liner ebuild change, probably the safest patch in the history of patches.
I'm CCing dev-portage@gentoo.org - as I see it, it's at best a WONTFIX for vlc.
Although the heuristics used by recent portage make the order irrelevant in this particular case, it used to make a difference for really old versions of portage. Due to behavior of older versions of portage (and apparently current versions of paludis), it's generally desirable to list newer atoms on the left side. However, this raises the question of whether or not the pms spec should specify a preferred heuristic for cases like this.
I've always been told that deps in a || get a preference from left to right, hence I consider this bug correct for vlc. Tomáš, since you changed it, could you please fix it for vlc ? (and probably check the changes you did to other packages since vlc is probably not the only one)
If ebuilds are allowed to rely upon Portage's heuristics for || ( ) selection, we need to document exactly what those heuristics are and not allow them to be changed. But if we do that, it prevents package managers from being clever in situations where Portage isn't clever, which is a bad thing. (e.g. if Portage can't figure out that if an early-on package does || ( a b ) and a later on package hard-deps upon b then it shouldn't take a, then other package managers and later Portage versions wouldn't be allow to do that either.) So we can't sensibly say anything beyond that ebuild authors should list 'best' things leftmost (even if some of those things are masked).
(In reply to comment #10) > I've always been told that deps in a || get a preference from left to right, > hence I consider this bug correct for vlc. > > Tomáš, since you changed it, could you please fix it for vlc ? (and probably > check the changes you did to other packages since vlc is probably not the only > one) > scarabeus, ping
(In reply to comment #12) > (In reply to comment #10) > > I've always been told that deps in a || get a preference from left to right, > > hence I consider this bug correct for vlc. > > > > Tomáš, since you changed it, could you please fix it for vlc ? (and probably > > check the changes you did to other packages since vlc is probably not the only > > one) > > > > scarabeus, ping > fixed it myself, don't dare to touch again a package i'm maintaining since you're completely ignoring requests to fix your mistakes...
Given the fact i just waited on arches to stabilise the 1.4 series of the libX11 so i can change the dep to simple >=libX11-version (which happened 2 days ago...)... But whatever. Anyway i can still touch any of your packages and you can't technicaly complain much if i do it from qa stance. And IT was not mistake at the time i wanted it to prefer the older version.
(In reply to comment #14) > > But whatever. Anyway i can still touch any of your packages and you can't > technicaly complain much if i do it from qa stance. > technically? I'm talking about politeness and cooperation... not a single reply in 2 months does not fall under these... QA or not you are expected to explain why you changed something in someone's else package if he asks you to, and fix it if he does ask to. Maybe next time I should make the request more public and with more threats since it seems to provide a quick answer... I'm sorry for thinking that a friendly request would be more appropriate. > Given the fact i just waited on arches to stabilise the 1.4 series of the > libX11 so i can change the dep to simple >=libX11-version (which happened 2 > days ago...)... [...] > And IT was not mistake at the time i wanted it to prefer the older version. ... and I'm sorry again, I lost my crystal ball, I didn't know...
(In reply to comment #14) > And IT was not mistake at the time i wanted it to prefer the older version. No, you didn't. It's never correct to prefer an older version. If you're claiming to be doing QA fixes then you should know that.
(In reply to comment #16) > (In reply to comment #14) > > And IT was not mistake at the time i wanted it to prefer the older version. > > No, you didn't. It's never correct to prefer an older version. If you're > claiming to be doing QA fixes then you should know that. > Learn to read. I said he cant tell me i cant touch his packages because i still can do it from qa stance. I did this change as normal x11 team member.. And since when it is wrong to preffer older version? (really i was not aware of this requirement) I was just not willing to change the code twice so i just waited for the arches to finish my stable request and be done with it.
(In reply to comment #15) > (In reply to comment #14) > > > > But whatever. Anyway i can still touch any of your packages and you can't > > technicaly complain much if i do it from qa stance. > > > > technically? I'm talking about politeness and cooperation... not a single reply > in 2 months does not fall under these... > QA or not you are expected to explain why you changed something in someone's > else package if he asks you to, and fix it if he does ask to. Maybe next time I > should make the request more public and with more threats since it seems to > provide a quick answer... I'm sorry for thinking that a friendly request would > be more appropriate. > > > Given the fact i just waited on arches to stabilise the 1.4 series of the > > libX11 so i can change the dep to simple >=libX11-version (which happened 2 > > days ago...)... > [...] > > And IT was not mistake at the time i wanted it to prefer the older version. > > ... and I'm sorry again, I lost my crystal ball, I didn't know... > Well i was reported this bug on the irc so i marked it as todo in my lovely head and just waited for the above to happen. Also i missed this bug as whole so you could've ping me normaly over irc or sent me direct mail. I guess i am not the only one whom get more than 300 bug mails daily in avg. The change was not breaking something in our official package manager so it has not severe impact. Plus i would really gladly explain it if pinged somehow differently than just being added somewhere to CC so i could actualy notice that ping.
(In reply to comment #17) > > No, you didn't. It's never correct to prefer an older version. If you're > > Learn to read. I said he cant tell me i cant touch his packages because i still > can do it from qa stance. And if you're claiming that you're allowed to do QA fixes then you really need to know more about QA. > And since when it is wrong to preffer older version? (really i was not aware of > this requirement) It's *always* wrong, and it always has been wrong. You *always* write best version leftmost. Even if that version is masked.
(In reply to comment #18) [...] > > Well i was reported this bug on the irc so i marked it as todo in my lovely > head and just waited for the above to happen. > Also i missed this bug as whole so you could've ping me normaly over irc or > sent me direct mail. I guess i am not the only one whom get more than 300 bug > mails daily in avg. > > The change was not breaking something in our official package manager so it has > not severe impact. Plus i would really gladly explain it if pinged somehow > differently than just being added somewhere to CC so i could actualy notice > that ping. > This argument is getting nowhere... you're trying to justify why you don't reply to bugs and try to justify your mistakes while you could just say "sorry I could have replied here" or just let it go if your ego doesn't allow it, and be done. (hint: doing this in the first time would have reduced the # of bug mails sent) It takes half a minute to fix, meaning I wasn't willing to waste time waiting for you or trying to run after you. I was working on vlc so fixed it meanwhile. I put a rant here to inform you that you should be more responsible for your commits, that's all...
