[OE-core] [PATCH 5/5] update-alternatives: Add alternatives as a runtime provide

[Richard Purdie]

On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
> On 8/2/11 8:46 AM, Phil Blundell wrote:
> > On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
> >> The following allows RPM to generate the SDK image, however without it
> >> we get a failure because the system has nothing that provides /bin/sh.
> >>
> >> Unfortunately the patch causes failures with ipk and deb packages because
> >> they can not have filenames within their RPROVIDES.  I'm looking for some
> >> type of a resolution to the issue, the only thing I can think of is to
> >> add a way to manually add a FILERPROVIDE for the items.  This will require
> >> changes to the way FILERPROVIDE is currently generated... but I'm not sure
> >> how we can automatically generate the FILERPROVIDE values without the use of
> >> python...
> >>
> >> Any suggestions?
> > 
> > It's never really been the intent that update-alternatives should put
> > the name of the link being provided into RPROVIDES.  If you want to
> > solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
> > += "virtual-bourne-shell" or something to bash and busybox is probably
> > the easiest way of doing that.
> > 
> > I wouldn't be entirely opposed to the concept of what you're proposing
> > here, though.  Something like:
> > 
> > RPROVIDES_${PN} += "${@' '.join(map(lambda x:
> > legitimize_package_name("virtual-path-" + x), filter(lambda x: x != '',
> > [ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
> > (d.getVar('ALTERNATIVE_LINKS', True) or '').split())))}"
> > 
> > might be what you want, perhaps.  I'm not sure that the resulting
> > virtual names will be very pretty though.
> 
> Hmm.. Coming from the RPM world, the virtual-path- because we can't just
> "provide" a file in the system seems a bit wonky to me.  But it should be able
> to work.  For RPM at least, we'd want a reversing function to turn virtual paths
> back into real paths.
> 
> If I have time today, I'll try to implement a proof of concept and see if I can
> get it to work reasonably well.

Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of "/bin/sh" is automatically fulfilled by
a package which contains "/bin/sh". Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.

I did chase down this bug a bit and it seems that if you "bitbake
meta-toolchain-game" you hit an error about /bin/sh being missing but if
you "bitbake busybox; bitbake meta-toolchain-gmae" it will work. This is
due to busybox shipping a /bin/sh.

The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure. 

Cheers,

Richard