On Sat, Apr 2, 2011 at 12:50, Pascal Terjan <pter...@gmail.com> wrote: > On Sat, Apr 2, 2011 at 08:57, Remy CLOUARD <shikam...@mandriva.org> wrote: >> On Wed, Mar 30, 2011 at 05:45:34PM +0200, Olivier Blin wrote: >>> Frank Griffin <f...@roadrunner.com> writes: >>> >>> > On 03/29/2011 03:01 PM, Ahmad Samir wrote: >>> >> [...] >>> >> “attach”... >>> >> >>> >> Anyway, from the log: >>> >> auto-select: adding lib64cairo-xcb2-1.10.2-4.mga1.x86_64 replacing >>> >> lib64cairo-xcb2-1.10.2-3.mga1.x86_64 >>> >> >>> >> which means you have lib64cairo-xcb2 installed (rpm -qa lib64cairo* >>> >> should confirm/deny); this is not the default, urpmi is set to prefer >>> >> lib(64)cairo2 over lib(64)cairo-xcb2, so I think, 'urpmi lib64cairo2' >>> >> should fix this issue. >>> > >>> > You're correct, but I'm damned if I know why. I have two cauldron >>> > systems which get updated via --auto-update exclusively. On one, I >>> > have >>> > >>> >>> [...] >>> >>> > Thanks for the assist, and sorry for the noise. >>> >>> There might have been a bug for a short time where pkgconfig(cairo) got >>> resolved to cairo-xcb-devel, so it is possible the wrong package got >>> pulled at some point. >>> >>> It should not be the case anymore (with a fix in urpmi >>> prefer.vendor.list), but it won't be fixed automatically for cauldron >>> users that got the "wrong" package before. >> Yep, sorry for that, I was unaware of that pkgconfig(cairo) provides. >> >> But f-spot’s case has been bugging me for quite some time. >> >> I don’t use it so I could not see the issue, but I don’t understand why >> it does have an explicit require on lib64cairo2… >> >> all its dependencies don’t. >> >> Here are the requires of f-spot : >> sqlite-tools >> sqlite3-tools >> lib64exif12 >> lib64gphoto2 >> shared-mime-info[*] >> scrollkeeper[*] >> shared-mime-info[*] >> scrollkeeper[*] >> /bin/sh[*] >> bash >> libX11.so.6()(64bit) >> libc.so.6()(64bit) >> libc.so.6(GLIBC_2.2.5)(64bit) >> libcairo.so.2()(64bit) >> libgdk-x11-2.0.so.0()(64bit) >> libgdk_pixbuf-2.0.so.0()(64bit) >> libglib-2.0.so.0()(64bit) >> liblcms.so.1()(64bit) >> libm.so.6()(64bit) >> libm.so.6(GLIBC_2.2.5)(64bit) >> libpthread.so.0()(64bit) >> rtld(GNU_HASH) >> pkgconfig >> lib64atk1.0_0 >> lib64cairo2 >> lib64gdk_pixbuf2.0_0 >> lib64gio2.0_0 >> lib64glib2.0_0 >> lib64gnomeui2_0 >> lib64gtk+-x11-2.0_0 >> lib64lcms1 >> lib64pango1.0_0 >> lib64unique0 >> lib64x11_6 >> lib64xcomposite1 >> mono(FlickrNet)[== 2.1.5.0] >> mono(Gnome.Keyring)[== 1.0.0.0] >> mono(ICSharpCode.SharpZipLib)[== 2.84.0.0] >> mono(Mono.Addins)[== 0.6.0.0] >> mono(Mono.Addins.Gui)[== 0.6.0.0] >> mono(Mono.Addins.Setup)[== 0.6.0.0] >> mono(Mono.Cairo)[== 2.0.0.0] >> mono(Mono.Posix)[== 2.0.0.0] >> mono(Mono.Simd)[== 2.0.0.0] >> mono(NDesk.DBus)[== 1.0.0.0] >> mono(System)[== 2.0.0.0] >> mono(System.Core)[== 3.5.0.0] >> mono(System.Web)[== 2.0.0.0] >> mono(System.Xml)[== 2.0.0.0] >> mono(atk-sharp)[== 2.12.0.0] >> mono(gconf-sharp)[== 2.24.0.0] >> mono(gdk-sharp)[== 2.12.0.0] >> mono(glib-sharp)[== 2.12.0.0] >> mono(gnome-sharp)[== 2.24.0.0] >> mono(gtk-sharp)[== 2.12.0.0] >> mono(mscorlib)[== 2.0.0.0] >> mono(pango-sharp)[== 2.12.0.0] >> >> >> As you can see, lib64cairo2 is completely unnecessary because the >> package already requires libcairo.so.2()(64bit). >> >> Looking at the spec: >> http://svnweb.mageia.org/packages/cauldron/f-spot/current/SPECS/f-spot.spec?revision=63695&view=markup >> >> I don’t understand line 43 to 45 though I’m not sure these are the one >> that pulls cairo, nor do I understand which problem Götz tried to work >> around. > > I think this is unrelated > All the lib64* requires are added automatically by something >
The code in mono-find-requires included in rpm-devel (from 2005, while mono-devel provides /usr/bin/mono-find-requires from 2008) contains a part to get the package name (and add "()(64bit)" on 64 bits...). I don't understand the comment. # Note about above: # Use to do: system("rpm -q --whatprovides --queryformat \"%{NAME}\n\" ""\""req"'$libext'""\"") # rpmlint prefers to have lib names instead of package names. There was a reason I was using package names but it slips me now... # Ah... now I remember... it's for noarch packs. The noarch packages can be built on either 32 or 64 bit... so we have to depend # on the package name instead.