Bug 4305

Summary: Smart reports "no package provides" when a conflict occurs
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Paul Eggleton <bluelightning>
Component: coreAssignee: Paul Eggleton <bluelightning>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: ionutx.chisanovici, jessica.zhang, meta.mr.watcher, meta.watcher
Version: 1.5   
Target Milestone: 1.5 M3   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
Log of conflict error none

Description Paul Eggleton 2013-04-15 15:35:14 UTC 
openssh conflicts with dropbear, so quite rightly smart won't let you install packagegroup-core-ssh-dropbear and openssh in the same image. However the issue comes when it reports the error back:

Computing transaction...error: Can't install packagegroup-core-ssh-dropbear-1.0-r1@all: no package provides dropbear

This is not helpful as it would be the same error if the package didn't exist. The error should actually say that it could not perform the installation because of a conflict.
Comment 1 Paul Eggleton 2013-04-15 15:39:44 UTC 
Created attachment 1173 [details]
Log of conflict error

Attached a log you get when building core-image-minimal with the following in local.conf:

CORE_IMAGE_EXTRA_INSTALL += "openssh"
EXTRA_IMAGE_FEATURES += "ssh-server-dropbear"
Comment 2 Paul Eggleton 2013-07-23 17:43:18 UTC 
This only happens sometimes; it appears that smart's transaction code is not deterministic, so if it attempts to install dropbear first it fails with the appropriate error:

error: Can't install dropbear-2013.58-r1.0@armv5te: it's conflicted by the locked package openssh-6.2p2-r0@armv5te

However if it goes to install openssh first and then later installs packagegroup-core-ssh-dropbear which itself does not conflict with openssh but depends on dropbear which does, you get the inferior error message about it not being provided. (For clarity, "install" anywhere above actually means a trial installation during transaction processing rather than the actual installation, so the non-deterministic nature of the process probably isn't an issue, it just acts as a trigger for the underlying problem.)

I've not yet figured out how to hack smart's transaction.py to fix this but I'm working on it.
Comment 4 Ionut Chisanovici 2013-10-21 07:11:28 UTC 
Verified using commit: 505114c13d29799a25379f7ce720d632616d8776