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

[Mark Hatle]

On 3/13/17 9:21 AM, Alexander Kanavin wrote:
> On 03/10/2017 06:54 PM, Mark Hatle wrote:
>> 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.
> 
>>>      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?)..
> 
> The variable name is misleading. That line up there is printing the 
> Provides list into the top section of the .spec file which is then given 
> to rpm so it can create binary packages.
> 
>> 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.)
> 
> I checked - rpm 4 does not have that feature now, or I couldn't find it.

We may need to add this feature.  It really is useful to deal with situations
like this.

>> 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.
> 
> This only affects nativesdk- packages, which are well isolated from all 
> other packages during installation time. I haven't seen any issues with 
> it either in my local testing or in the autobuilder run. If it pops up 
> somehow, we can do more to isolate the package sets.
> 

Thank you.  I understand now.

--Mark

> Alex
>