From clean, do a RPM build of a -dev image and you'll get an image construction failure: | error: Failed dependencies: | pkgconfig is needed by libz-dev-1.2.7-r0.i586 rpmdeps is adding a pkgconfig dependency to -dev packages which contain a .pc file, but I didn't build pkgconfig so there isn't a package to install. I'm a firm believer that just because a package ships a .pc it doesn't inherently depend on pkgconfig (the source package that wants to use pkgconfig does, and that's where the dependency should be), so we should patch that out of rpmdeps.
The dependency is 'real', in that the -dev packages do contain a .pc file, and to use it you need pkgconfig... it's just how do we tell the build system when to build it, if it's need is only detected after a given packages build-time. One possible solution to this is to treat pkgconfig as a required tool. It's small enough that it should be fairly quick to build the package and then ignore it from that point forward. The downside is pkgconfig depends on glib-2.0 and popt. So that might drag in additional dependencies that -do- take a lot longer to build. I've not traced the over all dependency set.
libz-dev doesn't require pkgconfig, as a program linking to libz doens't have to use pkgconfig (it could just #include <zlib.h> and hope for the best). The pkg-config dependency is always a build-dependency on the package that is using pkg-config.
Any package that provides a .pc file gets an automatic dependency on pkgconfig from the per-file dep generator used by RPM.. (and maybe someday by the other packaging backends.) There -are- -dev packages that do actually state a dependency on pkgconfig however.. libtelephony-dev is one of them. A specific dependence on pkgconfig is declared within the pkgconfig file itself. It's also very common that configure scripts for packages do depend on pkgconfig or on scripts that call pkgconfig. So for a -dev system we do need it, we just have to figure out the best way to add it to the mix. (Maybe the answer is if the IMAGE_FEATURES of dev-pkgs is enabled, pkgconfig is also built?)
"Any package that provides a .pc file gets an automatic dependency on pkgconfig from the per-file dep generator used by RPM" Yes, and that's what I was moaning about initially. If dev-pkgs pulls in pkgconfig why shouldn't it also pull in gcc, make, automake, scons, cmake, waf... If someone expects to actually compile stuff then they'll need to install the tools they'll need. tools-sdk is the obvious starting point there and the docs claim it pulls in pkgconfig. libtelepathy-glib having an explicit dependency on pkgconfig is interesting and I suspect very unusual. It depends on >= 0.21 which was released in 2006... we could easily patch that out and honestly I think asking upstream to remove it would work fine - it's serving no useful purpose.
I've just submitted a patch from telepathy-glib upstream that removes the pkgconfig dependency from telepathy-glib.pc. Are there any other pkgconfig files that do this?
We would need to audit the system. Using the RPM backend, you can query the packages and look for references of "pkgconfig(pkg-config)". This will point out any specific dependency on pkgconfig itself. Also, one alternative suggestion. We could change the hard dependencies for the 'pkgconfig....' into recommends instead. This would still ensure the right set of packages are installed, but would prevent failures if pkgconfig itself was not available. If this is a direction we want to look at, it will take some development. In OE we will need to have a way to filter the dependency list and move the pkgconfig items to be runtime-recommends... and we will have to extend RPM to add a way to specify the runtime-recommends (as opposed to requirements.)
*** Bug 3627 has been marked as a duplicate of this bug. ***
I'd suggest for now we just filter out the dependencies on pkgconfig itself...
I can't reproduce this on the latest master (HEAD at cfb082961a6c9ac3d65738031c4071210529cd07). I've tried RPM builds for both core-image-sato-dev and core-image-minimal-dev and both succeeded without errors. Do I need to do anything else?
Bogdan, Try these steps: 1. Start a new build form scratch for core-image-sato for lets say sugarbay BSP 2. Once step 1 is complete, then try building core-image-lsb-sdk It is possible that this issue may not happen while building lsb images from scratch. And in my testing I have built the lsb image always after building the sato image. Also Paul was working on this or similar bug, so I wonder if Paul has anything to say on this bug.
Paul, Do you have any thing to add on this bug?
Nitin, can you add your host info, I wonder if there some host difference that are getting involved between Nitin and Bogdan's system.
(In reply to comment #10) > Bogdan, > Try these steps: > > 1. Start a new build form scratch for core-image-sato for lets say sugarbay > BSP > 2. Once step 1 is complete, then try building core-image-lsb-sdk > > It is possible that this issue may not happen while building lsb images from > scratch. And in my testing I have built the lsb image always after building > the sato image. > > Also Paul was working on this or similar bug, so I wonder if Paul has > anything to say on this bug. Sorry, still no luck: /poky/buildx [] $ MACHINE=sugarbay bitbake core-image-sato Parsing recipes: 100% |#############################################################################################################################################################################| Time: 00:00:11 Parsing of 831 .bb files complete (0 cached, 831 parsed). 1139 targets, 32 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION = "1.17.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-12.10" TARGET_SYS = "x86_64-poky-linux" MACHINE = "sugarbay" DISTRO = "poky" DISTRO_VERSION = "1.3+snapshot-20130130" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "b3474:27c8af1e3a9092caa19bd813c4dd0747de766dc5" meta-intel meta-sugarbay = "master:5164713bfbef16e1a49bc599ec0d738df52ab254" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 5905 tasks of which 4982 didn't need to be rerun and all succeeded. /poky/buildx [] $ MACHINE=sugarbay bitbake core-image-lsb-sdk Loading cache: 100% |###############################################################################################################################################################################| ETA: 00:00:00 Loaded 1140 entries from dependency cache. Build Configuration: BB_VERSION = "1.17.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-12.10" TARGET_SYS = "x86_64-poky-linux" MACHINE = "sugarbay" DISTRO = "poky" DISTRO_VERSION = "1.3+snapshot-20130130" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "b3474:27c8af1e3a9092caa19bd813c4dd0747de766dc5" meta-intel meta-sugarbay = "master:5164713bfbef16e1a49bc599ec0d738df52ab254" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: dhcp: Files/directories were installed but not shipped /etc/dhclient.conf.example /etc/dhcpd.conf.example NOTE: Tasks Summary: Attempted 6817 tasks of which 4786 didn't need to be rerun and all succeeded. Summary: There was 1 WARNING message shown.
It is possible this is an sstate relocation issue caused by: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9a26b9c69c47c87ce71a06f76682c187767e7897 Were the people reproducing this building from an sstate cache that was built in an alternative location? I suspect Ross was since I know something about his setup. Nitin: What about you? To verify this issue, you need to clean out the sstate cache after applying the above fix since we don't track dependencies on native utils in the sstate hashes.
RP, I am not sharing the sstate cache across different machines. At the most I may have had updated the poky & meta-intel branches in between the separate image builds. Bogdan, If it is not reproducible anymore, we can close it now. Next time if I encounter it, I will try to gather more information for reproducing.
As per Nitin's indications, I am closing this bug as "not reproducible" for now.