GNOME Bugzilla – Bug 654701
consider hacks for Debian and other tar+wget wrappers that don't have RPM-like Provides: pkgconfig(foo)
Last modified: 2011-09-29 14:47:23 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=564373#c8 (In reply to comment #7) > > I don't think we should wait for a perfect solution. Package names differ at > this time between Fedora, Mandriva and openSuse. The pkgconfig($FOO) *works* > for Mandriva, openSuse and Fedora. I'm pretty sure Ubuntu/Debian will have > something similar, just terrible at figuring out what.. so I'll have to check. They don't client side, but we could query their web service: http://packages.debian.org/search?searchon=contents&keywords=glib-2.0.pc&mode=path&suite=stable&arch=any
or use http://en.wikipedia.org/wiki/Apt-file
(In reply to comment #1) > or use http://en.wikipedia.org/wiki/Apt-file The tricky part of this is that while you can expect the .pc file to be in /usr/lib/pkgconfig/foo.pc in 6.0, this will change for 7.0. But a 6.0 compatible sysdeps implementation would still be quite useful.
Maybe I missed the point, but it seems to me (quick read of bug #564373) you want something to install a specific DEB packgage (and of course related deps) starting from a pkg-config file, no full path involved. apt-file could help to find the proper package name, just like packages.debian.org, but working "locally". Unfortunately it seems sometimes it's unable to offer an unique package, but the same occurs using packages.debian.org :( Example: betatester@turnip:~$ apt-file search glib-2.0.pc libglib2.0-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc lsb-build-desktop3: /usr/lib/lsb3/pkgconfig/glib-2.0.pc (but I suspect you could filter out results with lsb3) betatester@turnip:~$ apt-file search bluez.pc libbluetooth-dev: /usr/lib/pkgconfig/bluez.pc libedbus-dev: /usr/lib/pkgconfig/ebluez.pc (I suspect here you need to play with strings in order to pick the proper one)
Sorry, my bad: betatester@turnip:~$ apt-file search /bluez.pc libbluetooth-dev: /usr/lib/pkgconfig/bluez.pc (no spurious ebluez.pc involved)
Too bad, that apt-file is not installed by default. I also wonder it the cache is keep up-to-date automatically. Then other then that "apt-file search /xxx.pc | grep '\-dev'" sounds like a good plan. Right now my bootstrap *hack* for jhbuild on ubuntu is: #!/bin/sh # get initial jhbuild deps installed modules=`jhbuild list | tr '\n' ' '` #sudo apt-get build-dep $modules for mod in $modules ; do apt-cache show >/dev/null 2>&1 $mod if test $? == 0 ; then sudo apt-get build-dep $mod fi done This works surprisingly well (even though e.g. it fails for glib, as the debian/ubuntu package is called libglib2). It would be easy to 'enhance' the script to also try "lib$mod"). Finally would be nice tou run "apt-get build-dep -y" but I am not sure if that would also answer 'y' to questions about deleting packages (which I would not want).
Created attachment 195300 [details] [review] systeminstall: Delete some dead code in PkSystemInstall
Created attachment 195301 [details] [review] systeminstall: Work around broken pkg-config installations On a stock Ubuntu Lucid install, pkg-config is broken in that xml2po.pc is missing, which causes pkg-config --modversion <list of pkgs> to fail. Work around this by forking for each package =(
Created attachment 195302 [details] [review] systeminstall: Add AptSystemInstall This currently only works on Ubuntu in practice because we run through sudo, which AFAIK isn't configured on Debian.
Created attachment 195303 [details] [review] systeminstall: Use pkexec over sudo Actually let's just use pkexec always; this should work on any Debian install that has policykit.
I should note with this that apt-file needs: 1) To be installed manually with apt-get install apt-file 2) To have a magic setup command run as root This patch doesn't handle either of those - but I think we should do it as part of a better "jhbuild bootstrap" which also takes care of ensuring you have gcc and the autotools. (Though I would be fine if someone decided instead to do it inside AptSystemInstall).
"systeminstall: Work around broken pkg-config installations" doesn't apply anymore, but was not required to test this. Minor deficiencies: - Wants to install ia32-libs-dev at it ships ia32 version of some required libs (libxml2 & libxslt at least), this is because it takes the first match in 'apt-file search' results, was there a reason not to take all of them? Past that we'd enter the realm of magic, like opting for the shortest path. - Won't pick the right version when a required package is provided in both unstable and experimental repositories (e.g. it will install libwebkitgtk-3.0-dev but default apt-get behaviour means it will take it from unstable, while that version is not sufficient). I believe this defect also exists in the PackageKit version, as pkgconfig(foobar.pc) is only concerned about the existence of foobar.pc, not its version number. - It should probably fallback on sudo if pkexec is not found, and not abort with an exception if credentials are not granted. Still it's probably best to commit this, despite those comments, and improve things afterwards.
Attachment 195300 [details] pushed as ab30e15 - systeminstall: Delete some dead code in PkSystemInstall Attachment 195301 [details] pushed as 9fb817c - systeminstall: Work around broken pkg-config installations Attachment 195302 [details] pushed as ffdf5b3 - systeminstall: Add AptSystemInstall Attachment 195303 [details] pushed as 562b703 - systeminstall: Use pkexec over sudo
(In reply to comment #11) > "systeminstall: Work around broken pkg-config installations" doesn't apply > anymore, but was not required to test this. I rebased it. > - Wants to install ia32-libs-dev at it ships ia32 version of some required > libs (libxml2 & libxslt at least), this is because it takes the first match in > 'apt-file search' results, was there a reason not to take all of them? Past > that we'd enter the realm of magic, like opting for the shortest path. Open to suggestions here. > - Won't pick the right version when a required package is provided in both > unstable and experimental repositories (e.g. it will install > libwebkitgtk-3.0-dev but default apt-get behaviour means it will take it from > unstable, while that version is not sufficient). I believe this defect also > exists in the PackageKit version, as pkgconfig(foobar.pc) is only concerned > about the existence of foobar.pc, not its version number. I don't know how to solve this. > - It should probably fallback on sudo if pkexec is not found, and not abort > with an exception if credentials are not granted. Fixed. > Still it's probably best to commit this, despite those comments, and improve > things afterwards. Yep.