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

login
register
mail settings
Submitter Mark Hatle
Date Aug. 2, 2011, 12:17 a.m.
Message ID <d97dcf096a3a72a2a087b2dbbcdd74c853f7e940.1312243899.git.mark.hatle@windriver.com>
Download mbox | patch
Permalink /patch/9022/
State New, archived
Headers show

Comments

Mark Hatle - Aug. 2, 2011, 12:17 a.m.
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?

-----

Add the automatic alternatives as runtime provides.

This was discovered when programers were requiring "/bin/sh" and there
was nothing within the system providing "/bin/sh", however bash had an
alternative for /bin/sh that would satisfy this dependency.

NOTE: THIS BREAKS IPK AND DEB PACKAGE GENERATION!  IT SHOULD NOT BE
MERGED!

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/classes/update-alternatives.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
Phil Blundell - Aug. 2, 2011, 1:46 p.m.
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.

p.
Mark Hatle - Aug. 2, 2011, 2:49 p.m.
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
Richard Purdie - Aug. 3, 2011, 12:20 p.m.
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
Mark Hatle - Aug. 3, 2011, 2:41 p.m.
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

Patch

diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
index ba81221..4cd680e 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -40,6 +40,8 @@ 
 ALTERNATIVE_PRIORITY = "10"
 ALTERNATIVE_LINK = "${bindir}/${ALTERNATIVE_NAME}"
 
+RPROVIDES_${PN} += "${@(d.getVar('ALTERNATIVE_LINK', True) or '') + ' ' + (d.getVar('ALTERNATIVE_LINKS', True) or '')}"
+
 update_alternatives_postinst() {
 update-alternatives --install ${ALTERNATIVE_LINK} ${ALTERNATIVE_NAME} ${ALTERNATIVE_PATH} ${ALTERNATIVE_PRIORITY}
 }