Patchwork [03/22] update-alternatives.bbclass: Add missing runtime dependency

login
mail settings
Submitter Mark Hatle
Date Dec. 4, 2012, 5:14 p.m.
Message ID <13c1d96727b678dc95430f1144b3017c9e62948f.1354641032.git.mark.hatle@windriver.com>
Download mbox | patch
Permalink /patch/40289/
State New
Headers show

Comments

Martin Jansa - Dec. 4, 2012, 5:04 p.m.
On Tue, Dec 04, 2012 at 11:14:35AM -0600, Mark Hatle wrote:
> When using update-alternatives, there should be a runtime dependency on
> update-alternatives.  Without this, it's possible to get into a situation
> where the package is not installable.
> 
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>  meta/classes/update-alternatives.bbclass |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
> index 4e1ff27..e432506 100644
> --- a/meta/classes/update-alternatives.bbclass
> +++ b/meta/classes/update-alternatives.bbclass
> @@ -304,6 +304,12 @@ python populate_packages_prepend () {
>              alt_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (alt_name, alt_target)
>  
>          if alt_setup_links:
> +            # RDEPENDS setup
> +            bb.note('adding runtime requirement for update-alternatives for %s' % pkg)
> +            rdepends = d.getVar('RDEPENDS_%s' % pkg, True) or ""
> +            rdepends += ' ' + d.getVar('MLPREFIX') + 'update-alternatives'
> +            d.setVar("RDEPENDS_%s" % pkg, rdepends)
> +

I guess you should use VIRTUAL-RUNTIME_update-alternatives here

Cheers,

>              bb.note('adding update-alternatives calls to postinst/postrm for %s' % pkg)
>              bb.note('%s' % alt_setup_links)
>              postinst = (d.getVar('pkg_postinst_%s' % pkg, True) or d.getVar('pkg_postinst', True)) or '#!/bin/sh\n'
> -- 
> 1.7.3.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Mark Hatle - Dec. 4, 2012, 5:14 p.m.
When using update-alternatives, there should be a runtime dependency on
update-alternatives.  Without this, it's possible to get into a situation
where the package is not installable.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/classes/update-alternatives.bbclass |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
Mark Hatle - Dec. 4, 2012, 5:34 p.m.
On 12/4/12 11:04 AM, Martin Jansa wrote:
> On Tue, Dec 04, 2012 at 11:14:35AM -0600, Mark Hatle wrote:
>> When using update-alternatives, there should be a runtime dependency on
>> update-alternatives.  Without this, it's possible to get into a situation
>> where the package is not installable.
>>
>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>> ---
>>   meta/classes/update-alternatives.bbclass |    6 ++++++
>>   1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
>> index 4e1ff27..e432506 100644
>> --- a/meta/classes/update-alternatives.bbclass
>> +++ b/meta/classes/update-alternatives.bbclass
>> @@ -304,6 +304,12 @@ python populate_packages_prepend () {
>>               alt_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (alt_name, alt_target)
>>
>>           if alt_setup_links:
>> +            # RDEPENDS setup
>> +            bb.note('adding runtime requirement for update-alternatives for %s' % pkg)
>> +            rdepends = d.getVar('RDEPENDS_%s' % pkg, True) or ""
>> +            rdepends += ' ' + d.getVar('MLPREFIX') + 'update-alternatives'
>> +            d.setVar("RDEPENDS_%s" % pkg, rdepends)
>> +
>
> I guess you should use VIRTUAL-RUNTIME_update-alternatives here

I believe what I have here is correct.  We don't care which update-alternatives 
we use, just that one is used.

recipes-devtools/dpkg/dpkg.inc:RPROVIDES_update-alternatives-dpkg += 
"update-alternatives"
recipes-devtools/opkg/opkg.inc:RPROVIDES_update-alternatives-cworth += 
"update-alternatives"

If I use the ${VIRTUAL-RUNTIME_update-alternatives} that has the effect or hard 
coding which specific version of update-alternatives we're going to use.. (-dpg 
vs -cworth)  I'm not sure this is really the desired behavior in this case -- if 
it is, it's easy enough to change of course.

--Mark

> Cheers,
>
>>               bb.note('adding update-alternatives calls to postinst/postrm for %s' % pkg)
>>               bb.note('%s' % alt_setup_links)
>>               postinst = (d.getVar('pkg_postinst_%s' % pkg, True) or d.getVar('pkg_postinst', True)) or '#!/bin/sh\n'
>> --
>> 1.7.3.4
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Richard Purdie - Dec. 4, 2012, 8:46 p.m.
On Tue, 2012-12-04 at 11:34 -0600, Mark Hatle wrote:
> On 12/4/12 11:04 AM, Martin Jansa wrote:
> > On Tue, Dec 04, 2012 at 11:14:35AM -0600, Mark Hatle wrote:
> >> When using update-alternatives, there should be a runtime dependency on
> >> update-alternatives.  Without this, it's possible to get into a situation
> >> where the package is not installable.
> >>
> >> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> >> ---
> >>   meta/classes/update-alternatives.bbclass |    6 ++++++
> >>   1 files changed, 6 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
> >> index 4e1ff27..e432506 100644
> >> --- a/meta/classes/update-alternatives.bbclass
> >> +++ b/meta/classes/update-alternatives.bbclass
> >> @@ -304,6 +304,12 @@ python populate_packages_prepend () {
> >>               alt_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (alt_name, alt_target)
> >>
> >>           if alt_setup_links:
> >> +            # RDEPENDS setup
> >> +            bb.note('adding runtime requirement for update-alternatives for %s' % pkg)
> >> +            rdepends = d.getVar('RDEPENDS_%s' % pkg, True) or ""
> >> +            rdepends += ' ' + d.getVar('MLPREFIX') + 'update-alternatives'
> >> +            d.setVar("RDEPENDS_%s" % pkg, rdepends)
> >> +
> >
> > I guess you should use VIRTUAL-RUNTIME_update-alternatives here
> 
> I believe what I have here is correct.

No, Martin is right.

>   We don't care which update-alternatives 
> we use, just that one is used.
> 
> recipes-devtools/dpkg/dpkg.inc:RPROVIDES_update-alternatives-dpkg += 
> "update-alternatives"
> recipes-devtools/opkg/opkg.inc:RPROVIDES_update-alternatives-cworth += 
> "update-alternatives"
> 
> If I use the ${VIRTUAL-RUNTIME_update-alternatives} that has the effect or hard 
> coding which specific version of update-alternatives we're going to use.. (-dpg 
> vs -cworth)  I'm not sure this is really the desired behavior in this case -- if 
> it is, it's easy enough to change of course.

I keep telling people this and people keep ignoring me.

We DO NOT SUPPORT switching providers at runtime since its a package
manager specific problem for which we currently have no general
abstraction.

This leads to patches like:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fe21ace36e19e06cbfdb83f73e60623bd4e382af

since the virtual/ space does not somehow magically work at runtime,
worse it breaks the deb package backend.

PREFERRED_PROVIDER is a build time thing. virtual/ is a build time
thing. How do I explain this any clearer?

The only mechanism for distro selection of runtime is VIRTUAL-RUNTIME_
which is pretty horrible and likely would be better done with something
debian package renaming like since we already have that mangling code.

Cheers,

Richard
Mark Hatle - Dec. 5, 2012, 1:47 a.m.
On 12/4/12 2:46 PM, Richard Purdie wrote:
> On Tue, 2012-12-04 at 11:34 -0600, Mark Hatle wrote:
>> On 12/4/12 11:04 AM, Martin Jansa wrote:
>>> On Tue, Dec 04, 2012 at 11:14:35AM -0600, Mark Hatle wrote:
>>>> When using update-alternatives, there should be a runtime dependency on
>>>> update-alternatives.  Without this, it's possible to get into a situation
>>>> where the package is not installable.
>>>>
>>>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>>>> ---
>>>>    meta/classes/update-alternatives.bbclass |    6 ++++++
>>>>    1 files changed, 6 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
>>>> index 4e1ff27..e432506 100644
>>>> --- a/meta/classes/update-alternatives.bbclass
>>>> +++ b/meta/classes/update-alternatives.bbclass
>>>> @@ -304,6 +304,12 @@ python populate_packages_prepend () {
>>>>                alt_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (alt_name, alt_target)
>>>>
>>>>            if alt_setup_links:
>>>> +            # RDEPENDS setup
>>>> +            bb.note('adding runtime requirement for update-alternatives for %s' % pkg)
>>>> +            rdepends = d.getVar('RDEPENDS_%s' % pkg, True) or ""
>>>> +            rdepends += ' ' + d.getVar('MLPREFIX') + 'update-alternatives'
>>>> +            d.setVar("RDEPENDS_%s" % pkg, rdepends)
>>>> +
>>>
>>> I guess you should use VIRTUAL-RUNTIME_update-alternatives here
>>
>> I believe what I have here is correct.
>
> No, Martin is right.
>
>>    We don't care which update-alternatives
>> we use, just that one is used.
>>
>> recipes-devtools/dpkg/dpkg.inc:RPROVIDES_update-alternatives-dpkg +=
>> "update-alternatives"
>> recipes-devtools/opkg/opkg.inc:RPROVIDES_update-alternatives-cworth +=
>> "update-alternatives"
>>
>> If I use the ${VIRTUAL-RUNTIME_update-alternatives} that has the effect or hard
>> coding which specific version of update-alternatives we're going to use.. (-dpg
>> vs -cworth)  I'm not sure this is really the desired behavior in this case -- if
>> it is, it's easy enough to change of course.
>
> I keep telling people this and people keep ignoring me.
>
> We DO NOT SUPPORT switching providers at runtime since its a package
> manager specific problem for which we currently have no general
> abstraction.

We do support switching providers already, that's the whole alternatives system 
itself.  What is different is in this case we can't use the update-alternatives.

But with the RPROVIDE of update-alternatives within the dpkg and opkg code..  We 
can certainly require 'update-alterantives' and the packaging systems will do 
the right thing (they have so far...)

> This leads to patches like:
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fe21ace36e19e06cbfdb83f73e60623bd4e382af
>
> since the virtual/ space does not somehow magically work at runtime,
> worse it breaks the deb package backend.

It works in RPM... but if it doesn't in deb (and ipk) I understand the 
limitations we are bound to.  Limiting the character space (i.e. no '/') is 
different then saying we don't support RPROVIDES...

> PREFERRED_PROVIDER is a build time thing. virtual/ is a build time
> thing. How do I explain this any clearer?

I'm still confused on the PREFERRED_PROVIDER honestly.

conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_virtual/update-alternatives 
?= "update-alternatives-cworth"
conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_virtual/update-alternatives-native 
?= "opkg-native"

There is no 'update-alternatives-cworth' recipe.. but there is an opkg recipe 
that happens to provide an update-alternatives-cworth -package-.  So does 
PREFERRED_PROVIDER select packages or recipes?

> The only mechanism for distro selection of runtime is VIRTUAL-RUNTIME_
> which is pretty horrible and likely would be better done with something
> debian package renaming like since we already have that mangling code.

And the VIRTUAL-RUNTIME isn't a runtime selection, it's a build-time selection. 
  If we need to select this at build-time, we can.  I'm happy with changing the 
patch, but as a distribution person I really don't care who provides this as 
long as something does.

--Mark

> Cheers,
>
> Richard
>
>
Richard Purdie - Dec. 5, 2012, 9:17 a.m.
On Tue, 2012-12-04 at 19:47 -0600, Mark Hatle wrote:
> On 12/4/12 2:46 PM, Richard Purdie wrote:
> > On Tue, 2012-12-04 at 11:34 -0600, Mark Hatle wrote:
> > I keep telling people this and people keep ignoring me.
> >
> > We DO NOT SUPPORT switching providers at runtime since its a package
> > manager specific problem for which we currently have no general
> > abstraction.
> 
> We do support switching providers already, that's the whole alternatives system 
> itself.  What is different is in this case we can't use the update-alternatives.

We do support update alternatives, yes. We're talking about something
else here though.

> But with the RPROVIDE of update-alternatives within the dpkg and opkg code..  We 
> can certainly require 'update-alterantives' and the packaging systems will do 
> the right thing (they have so far...)

Ok, let me put this a different way. What exactly tells tells the
package manager what it should be installing as "update-alternatives"?
Where is the variable that controls this?

I think you will find there isn't any mechanism for it. The only reason
it does the right thing is a combination of:

a) We've configured things to only build one provider in most cases
b) We use the VIRTUAL-RUNTIME_update-alternatives substitution that 
   Martin mentions.

> > This leads to patches like:
> >
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fe21ace36e19e06cbfdb83f73e60623bd4e382af
> >
> > since the virtual/ space does not somehow magically work at runtime,
> > worse it breaks the deb package backend.
> 
> It works in RPM... but if it doesn't in deb (and ipk) I understand the 
> limitations we are bound to.  Limiting the character space (i.e. no '/') is 
> different then saying we don't support RPROVIDES...

We support RPROVIDES, no argument. What we don't have is any mechanism
to indicate to *any* of the package managers that if there are two
providers, which one should be preferred.

The character was just a detail, the whole approach was also flawed, at
least as the system stands today :(.

> > PREFERRED_PROVIDER is a build time thing. virtual/ is a build time
> > thing. How do I explain this any clearer?
> 
> I'm still confused on the PREFERRED_PROVIDER honestly.

That much is clear from the email :/. It only works for build time
resolution, not package management.

> conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_virtual/update-alternatives 
> ?= "update-alternatives-cworth"
> conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_virtual/update-alternatives-native 
> ?= "opkg-native"
> 
> There is no 'update-alternatives-cworth' recipe.. but there is an opkg recipe 
> that happens to provide an update-alternatives-cworth -package-.  So does 
> PREFERRED_PROVIDER select packages or recipes?

It works in "build" namespace, namely DEPENDS and PROVIDES, so recipes.

Recipes can have additional PROVIDES other than their name, not to be
confused with RPROVIDES which is package namespace and separate.

We have no support for PREFERRED_RPROVIDER for example since that would
have to get communicated to the package manager. It would be interesting
to see that work...

> > The only mechanism for distro selection of runtime is VIRTUAL-RUNTIME_
> > which is pretty horrible and likely would be better done with something
> > debian package renaming like since we already have that mangling code.
> 
> And the VIRTUAL-RUNTIME isn't a runtime selection, it's a build-time selection. 

I realise that. As I said earlier, we don't support runtime selection
and we allow distro selection of some things (at build time) using this
rather ugly mechanism. I'd love to have something neater but its hard to
interface that into all the packaging backends.

>   If we need to select this at build-time, we can.

Rightly or wrongly, we need to.

>   I'm happy with changing the 
> patch, but as a distribution person I really don't care who provides this as 
> long as something does.

We care about deterministic builds so we have to care about details like
this.

Cheers,

Richard

Patch

diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
index 4e1ff27..e432506 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -304,6 +304,12 @@  python populate_packages_prepend () {
             alt_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (alt_name, alt_target)
 
         if alt_setup_links:
+            # RDEPENDS setup
+            bb.note('adding runtime requirement for update-alternatives for %s' % pkg)
+            rdepends = d.getVar('RDEPENDS_%s' % pkg, True) or ""
+            rdepends += ' ' + d.getVar('MLPREFIX') + 'update-alternatives'
+            d.setVar("RDEPENDS_%s" % pkg, rdepends)
+
             bb.note('adding update-alternatives calls to postinst/postrm for %s' % pkg)
             bb.note('%s' % alt_setup_links)
             postinst = (d.getVar('pkg_postinst_%s' % pkg, True) or d.getVar('pkg_postinst', True)) or '#!/bin/sh\n'