[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