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

[Mark Hatle <mark.hatle@windriver.com>]

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.

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core