[OE-core] [PATCH 34/44] package_rpm.bbclass: add a /bin/sh Provides for nativesdk- packages

Mark Hatle mark.hatle at windriver.com
Fri Mar 10 16:54:31 UTC 2017


On 3/10/17 5:24 AM, Alexander Kanavin wrote:
> nativesdk-* rpm packages all require /bin/sh because postinst scriptlets
> are run with it. We can either teach rpm4 and dnf to ignore that dependency
> (a lot of non-upstreamable work), or add auto-satisfy the dependency
> in each package. I've chosen to do the latter.
> 
> Signed-off-by: Alexander Kanavin <alexander.kanavin at linux.intel.com>
> ---
>  meta/classes/package_rpm.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
> index ff86dc87980..2cdaae0ff25 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -560,7 +560,7 @@ python write_specfile () {
>  
>      print_deps(srcrrecommends, "Recommends", spec_preamble_top, d)
>      print_deps(srcrsuggests, "Suggests", spec_preamble_top, d)
> -    print_deps(srcrprovides, "Provides", spec_preamble_top, d)
> +    print_deps(srcrprovides + (" /bin/sh" if srcname.startswith("nativesdk-") else ""), "Provides", spec_preamble_top, d)
>      print_deps(srcrobsoletes, "Obsoletes", spec_preamble_top, d)

I'm confused as to what this is doing...   I see this is only affecting the
virtual 'src package' (or the one built for archiving?)..

But providing /bin/sh as any type of provide seems wrong.  Either --nodeps to
the rpmbuild or there should be a configuration file that the (host/cross) rpm
can use to say "yes I really just have /bin/sh.

(rpm5 has a single file you could put arbitrary file provides into, at one point
rpm4 did as well -- but I don't know if it's still there.)

Doing this runs the risk of someone asking for '/bin/sh' and getting a source
package (a random one) as part of their build process using the DNF sources
option and such.  Definitely not what is expected.

>      
>      # conflicts can not be in a provide!  We will need to filter it.
> 




More information about the Openembedded-core mailing list