Bug 5204

I see two problems here:

- curl-certs is an empty package. there's nothing out of FILES_${PN}-certs = "${datadir}/curl/curl-*"

- there's NO dependency between curl and curl-certs. libcurl _recommends_ curl-certs:

RRECOMMENDS_lib${BPN} += "${PN}-certs"

but I can't find any place where curl is declared to _depend_ on curl-certs.

Are there two different bugs in one here?

It looks like a problem with the "smart" package manager.

If you download curl, and install one using rpm directly, the "Suggest" tag in the SPEC file is working properly.

root@romley:~# smart download curl
Loading cache...
Updating cache...                                       ############################################################################# [100%]

root@romley:~# smart download libcurl4
Loading cache...
Updating cache...                                       ############################################################################# [100%]

root@romley:~# rpm -ih libcurl4-7.29.0-r1.x86_64.rpm 
########################################### [100%]
########################################### [100%]

root@romley:~# rpm -ih curl-7.29.0-r1.x86_64.rpm 
########################################### [100%]
########################################### [100%]

The dependency of curl-certs is avoid in this case, so "smart" the responsible of this problem.

might be worth trying to reproduce this using either BAD_RECOMMENDATIONS = "curl-certs" or NO_RECOMMENDATIONS = "1"  to see if the issue goes away.

Those variables didn't work for me in a curl bbappend recipe.

(In reply to comment #3)
> might be worth trying to reproduce this using either BAD_RECOMMENDATIONS =
> "curl-certs" or NO_RECOMMENDATIONS = "1"  to see if the issue goes away.

I've tried on qemux86 and nuc machines on both dylan and master and have not been able to reproduce this issue - curl installs without error here. I'm not sure what I'm doing differently but clearly I'm not replicating your setup (aside from not being able to test on a romley machine).

Mark, this bug is against dylan so those variables wouldn't be applicable.

Paul which curl version comes when you try to "smart install" it? May be there were an update somewhere in the mean time ?

It's the same version here. The problem here is definitely to do with smart, rpm, or the data being fed into them, rather than curl.

Can you tell me what output you get with the following commands?

 smart query --show-recommends libcurl4

 smart query --show-requires libcurl4

Actually I suspect I know what might be going on. Did you manually run your host distro's version of createrepo on the host rpm repositories? I know we advise people to do that but it occurs to me now that that might not be a good idea because it probably won't index the recommends properly.

Going to a new build I now have libcurl5 instead of 4? Dunno what I might have done wrong here (I don't see significant update in meta/recipes-support?). 

Anyway, your intuition is right, I'm running createrepo on the rpm directory. Should this be the problem, what are the alternatives?

Here the requested logs:

# smart query --show-recommends libcurl5

libcurl5-7.29.0-r1@armv5te
  Recommends:
    curl-certs

# smart query --show-requires libcurl5

libcurl5-7.29.0-r1@armv5te
  Requires:
    /bin/sh [pre]
    libc.so.6(GLIBC_2.17)
    libc6 >= 2.17 [pre]
    libc6 >= 2.17
    libcap.so.2 [pre]
    libcap.so.2
    libcap2 >= 2.22 [pre]
    libcap2 >= 2.22
    libgcc1 >= 4.7.2 [pre]
    libgcc1 >= 4.7.2
    libgcc_s.so.1 [pre]
    libgcc_s.so.1
    libgcc_s.so.1(GCC_3.5) [pre]
    libgcc_s.so.1(GCC_3.5)
    libgcrypt.so.11 [pre]
    libgcrypt.so.11
    libgcrypt.so.11(GCRYPT_1.2) [pre]
    libgcrypt.so.11(GCRYPT_1.2)
    libgcrypt11 >= 1.5.0 [pre]
    libgcrypt11 >= 1.5.0
    libgnutls.so.26 [pre]
    libgnutls.so.26
    libgnutls.so.26(GNUTLS_1_4) [pre]
    libgnutls.so.26(GNUTLS_1_4)
    libgnutls26 >= 2.12.23 [pre]
    libgnutls26 >= 2.12.23
    libgpg-error.so.0 [pre]
    libgpg-error.so.0
    libgpg-error0 >= 1.11 [pre]
    libgpg-error0 >= 1.11
    libpthread.so.0 [pre]
    libpthread.so.0
    libpthread.so.0(GLIBC_2.4) [pre]
    libpthread.so.0(GLIBC_2.4)
    libtasn1-3 >= 2.14 [pre]
    libtasn1-3 >= 2.14
    libtasn1.so.3 [pre]
    libtasn1.so.3
    libz.so.1 [pre]
    libz.so.1
    libz1 >= 1.2.7 [pre]
    libz1 >= 1.2.7
    rtld(GNU_HASH) [pre]
    rtld(GNU_HASH)

So the fix really is to use the version of createrepo we build within the build system; this has been patched to support recommends. FYI this is the version we use to create the indexes when an image is built; so if you built an image and then used the feeds from the target immediately afterwards you shouldn't see the problem (and I'm guessing that's what you've done just now with your most recent build?)

Of course, having to rebuild an image every time to update the indexes would be a pain. The good news is there is "bitbake package-index" which will do this; the bad news is I just found yesterday that it's broken. However, the fix is now in master, is fairly straightforward and applies cleanly on top of dylan:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2f64fae60b3f61a2c45dc9e5314d2d16b1e64605

Apply that and then you should be able to run "bitbake package-index" to update the indexes instead of running your host's createrepo. However note that this does mean you need to add channels for each package architecture rather than just one for all, since that's how we index them.

Wow...

- bitbake package-index does not fail at home without your patch :(
- smart cannot find a new package, even after a package-index :( ??

Is there something in the workflow I should have missed ? 

What I've done:
- create image
- add repo to image
- smart search cmake (i used cmake as a test as it's missing from my image)
- from my host, bitbake cmake, bitbake package-index
- smart update
- smart search cmake : still nothing :(

It won't always actually error out without my patch - but it'll always fail to update the package index properly (it misses out the important package architectures). See bug #5278 for details.

So the steps you performed were with my patch or still without?

Well I did it with your patch but had missed the comment about entering one repo per directory. I added them and now the flow is ok. 

I need to rebuild an image without curl to check if the dependency issue is solved or not...

Things are getting better, but now I face a new issue. In the following install (with the use of bitbake package-index) :
root@qemuarm:~# smart install URI-Escape-XS
Loading cache...
Updating cache...                                        ############################################################################## [100%]

Computing transaction...

Installing packages (9):
  URI-Escape-XS-0.10-r0@armv5te                                         libgcc1-4.7.2-r20@armv5te                                             
  busybox-1.20.2-r11@armv5te                                            libperl5-5.14.3-r1@armv5te                                            
  busybox-syslog-1.20.2-r11@armv5te                                     perl-5.14.3-r1@armv5te                                                
  busybox-udhcpc-1.20.2-r11@armv5te                                     update-alternatives-cworth-1:0.1.8+svnr649-r13.0@armv5te              
  libc6-2.17-r3@armv5te                                                 

358.9kB of package files are needed. 5.0MB will be used.

Confirm changes? (Y/n): Y

Fetching packages...                                                                                                                          
-> http://192.168.7.1:81/rpm/armv5te/busybox-syslog-1.20.2-r11.armv5te.rpm                                                                    
busybox-syslog-1.20.2-r11.armv5te.rpm                    ############################################################################## [ 66%]
-> http://192.168.7.1:81/rpm/armv5te/busybox-udhcpc-1.20.2-r11.armv5te.rpm                                                                    
busybox-udhcpc-1.20.2-r11.armv5te.rpm                    ############################################################################## [ 77%]
-> http://192.168.7.1:81/rpm/armv5te/URI-Escape-XS-0.10-r0.armv5te.rpm                                                                        
URI-Escape-XS-0.10-r0.armv5te.rpm                        ############################################################################## [ 88%]
-> http://192.168.7.1:81/rpm/armv5te/busybox-1.20.2-r11.armv5te.rpm                                                                           
busybox-1.20.2-r11.armv5te.rpm                           ############################################################################## [100%]

                                                                                                                                              
Committing transaction...
error: busybox-syslog-1.20.2-r11 requires /dev/null                                                                                           



Note that if I "smart download" the package and "rpm -i" it, I don't face the same issue....

This is very strange. What do you get if you do:

smart query --show-all busybox-syslog

Changing to NEEDINFO as per above.

Hi Paul, 
Sorry for the lag in the reply. Here's the command result:

busybox-syslog-1.20.2-r11@armv5te {0} [local3] - Tiny versions of many common UNIX utilities in a single small executable.
  Provides:
    busybox-syslog = 1.20.2-r11@armv5te
    busybox-syslog-systemd
  Requires:
    /bin/sh
      Provided By:
        bash-4.2-r6@armv5te (/bin/sh)
        busybox-1.20.2-r11@armv5te (/bin/sh)
    update-alternatives-cworth
        update-alternatives-cworth-1:0.1.8+svnr649-r13.0@armv5te (update-alternatives-cworth = 1:0.1.8+svnr649-r13.0@armv5te)
  Upgrades:
    busybox-syslog < 1.20.2-r11@armv5te
    busybox-syslog-systemd
  Conflicts:
    busybox-syslog-systemd

Hmm, no mention of /dev/null in there.

Right now I'm at a bit of a loss unless I can reproduce this here. Can you provide me with a bit more information as to how you have set up your build so I can try to do the same here?

Setting as NEEDINFO again as per above - can you help me to reproduce this?

I'm marking this as resolved - I can't reproduce the problem. If you can still reproduce the issue and you're able to help me to do so I'm more than happy to investigate it further; in which case please reopen the bug.