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

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

On 8/3/11 7:20 AM, Richard Purdie wrote:
> 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. 

Due to deb/ipk not handling file based dependencies, they are filtered out on
the creation of the deb/ipk packages.  The original intention was to use them,
but it wasn't possible at the time.  Simply adding a ton of file-based
dependencies seemed like a huge mistake as well.  (We'd have to add virtual
provides for all of the virtual requirements....)

We could certainly select a few specific requirements and scan for and use those
to catch obvious issues, such as perl, sh, bash, env/python... but it's still
only a partial solution to the real issue.

--Mark

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