preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

Hi,

Recently the FSO developers discovered that they can put

RPROVIDES = "foo"
RCONFLICTS = "foo"

in their fso-foo recipe to have OE install fso-foo instead of foo in 
their fso-image. Great.

The downside: people can't get 'foo' anymore in their image since 
'fso-foo' will _always_ get choosen over 'foo'. Not so great.

Normally it would be just a matter of putting PREFERRED_PROVIDER_foo = 
"foo" in the distro.conf, but that is not an option in this case, since 
when building 'fso-image' I actually want 'fso-foo' instead of 'foo'

My proposal is:

* remove the RPROVIDES, leave the RCONFLICTS
* put 'fso-foo' in IMAGE_INSTALL in fso-images instead of 'foo'
* educate people using RPROVIDES, RCONFLICTS and RREPLACES in recipes

objections?

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Michael 'Mickey' Lauer]

Sounds good overall, however there is still the problem with things like e.g. 
gpsd. If you remove fso-gpsd's RPROVIDES=gspd, then anything that rdepends on 
gpsd will bring us gpsd back into the [fso-]image, hence we have a conflict 
again.

-- 
:M:

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 17:55, Michael 'Mickey' Lauer wrote:
> Sounds good overall, however there is still the problem with things like e.g.
> gpsd. If you remove fso-gpsd's RPROVIDES=gspd, then anything that rdepends on
> gpsd will bring us gpsd back into the [fso-]image, hence we have a conflict
> again.

At this point user get messages like "not downgrading gpsd to <version 
from fso-gpsd" which it also not what we want.

You can't protect against user messing up their systems and right now 
fso-gpsd is messing up the system of non fso-users, which is bad.

I understand the problem, but the current situation is unacceptable.

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Phil Blundell]

On Wed, 2008-11-26 at 17:55 +0100, Michael 'Mickey' Lauer wrote:
> Sounds good overall, however there is still the problem with things like e.g. 
> gpsd. If you remove fso-gpsd's RPROVIDES=gspd, then anything that rdepends on 
> gpsd will bring us gpsd back into the [fso-]image, hence we have a conflict 
> again.

It sounds like you have a namespacing problem here.  If there are
packages which need to depend on some abstract gpsd API or ABI, they
should probably be Depending on "virtual/gpsd" or the like and this
virtual package should be Provided by both gpsd and fso-gpsd.

Semi-virtual packages (i.e. a given name existing both as a concrete
package and as a Provides: in some other package) basically do not work:
this is partly an implementation problem in opkg but there is also a
fundamentally insoluble problem with versioning.  About the only time
that adding a Provides: for the same name as an existing concrete
package is the right thing to do, is when one package completely
supercedes each other; in this case you would generally also say that
the new one Replaces: and Conflicts: with the old one.

p.

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 18:40, Phil Blundell wrote:
> On Wed, 2008-11-26 at 17:55 +0100, Michael 'Mickey' Lauer wrote:
>> Sounds good overall, however there is still the problem with things like e.g.
>> gpsd. If you remove fso-gpsd's RPROVIDES=gspd, then anything that rdepends on
>> gpsd will bring us gpsd back into the [fso-]image, hence we have a conflict
>> again.
>
> It sounds like you have a namespacing problem here.  If there are
> packages which need to depend on some abstract gpsd API or ABI, they
> should probably be Depending on "virtual/gpsd" or the like and this
> virtual package should be Provided by both gpsd and fso-gpsd.
>
> Semi-virtual packages (i.e. a given name existing both as a concrete
> package and as a Provides: in some other package) basically do not work:
> this is partly an implementation problem in opkg but there is also a
> fundamentally insoluble problem with versioning.  About the only time
> that adding a Provides: for the same name as an existing concrete
> package is the right thing to do, is when one package completely
> supercedes each other; in this case you would generally also say that
> the new one Replaces: and Conflicts: with the old one.

Conflicts: + Replaces: hits another bug in opkg, it will silently pick 
'fso-foo' over 'foo' when both are in deploy (e.g. build fso-image for 
om-gta02 and x11-image-with-gpsd for om-gta01). We hit this problem when 
the matchbox-*2 was added from poky.
The good news is that opkg is maintained now so this problem can be fixed :)

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Phil Blundell]

On Wed, 2008-11-26 at 18:49 +0100, Koen Kooi wrote:
> Conflicts: + Replaces: hits another bug in opkg, it will silently pick 
> 'fso-foo' over 'foo' when both are in deploy (e.g. build fso-image for 
> om-gta02 and x11-image-with-gpsd for om-gta01). We hit this problem when 
> the matchbox-*2 was added from poky.

I'm not quite sure what you're saying here.  If fso-foo Conflicts,
Replaces, and Provides foo, opkg would be basically correct to install
the former rather than the latter package.  What exactly is the
behaviour you're observing?

p.

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 19:03, Phil Blundell wrote:
> On Wed, 2008-11-26 at 18:49 +0100, Koen Kooi wrote:
>> Conflicts: + Replaces: hits another bug in opkg, it will silently pick
>> 'fso-foo' over 'foo' when both are in deploy (e.g. build fso-image for
>> om-gta02 and x11-image-with-gpsd for om-gta01). We hit this problem when
>> the matchbox-*2 was added from poky.
>
> I'm not quite sure what you're saying here.  If fso-foo Conflicts,
> Replaces, and Provides foo, opkg would be basically correct to install
> the former rather than the latter package.  What exactly is the
> behaviour you're observing?

if fso-foo has

Conflicts: foo
Replaces: foo

but not

Provides: foo

opkg will always pick fso-foo when it's present in deploy, while you 
want an image with foo.

The whole problem is that for some images I do *not* want to drag in 
python, frameworkd and other things when I just want /usr/bin/apm or 
/usr/bin/gpsd. But for fso-*-image I *do* want fso-gpsd and fso-apm.

If the fso stuff was API+ABI compatible and about the same size I 
wouldn't care about this, but right now it's a ~5MiB difference, not to 
mention the runtime speed penalty of needing a python interpreter.

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Phil Blundell]

On Wed, 2008-11-26 at 19:40 +0100, Koen Kooi wrote:
> if fso-foo has
> 
> Conflicts: foo
> Replaces: foo
> 
> but not
> 
> Provides: foo
> 
> opkg will always pick fso-foo when it's present in deploy, while you 
> want an image with foo.

Are you sure that your package fso-foo really wants to Conflict: with
and Replace: foo without also Providing: it?  Although I don't think
there is any reason why this is inherently illegitimate, it is certainly
something of a fringe case and my first suspicion would be that this is
a packaging bug which is just happening to tickle an opkg bug and/or
misfeature.  I suspect opkg is taking a slightly harder line on this,
deciding that lack of Provides: in this case must certainly be a
packaging error, and proceeding as if that Provides: was present.  It's
debatable whether this is a desirable thing for it to be doing but,
irrespective of that, at least a part of the right answer is probably to
fix the offending packages.

p.

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 20:00, Phil Blundell wrote:
> On Wed, 2008-11-26 at 19:40 +0100, Koen Kooi wrote:
>> if fso-foo has
>>
>> Conflicts: foo
>> Replaces: foo
>>
>> but not
>>
>> Provides: foo
>>
>> opkg will always pick fso-foo when it's present in deploy, while you
>> want an image with foo.
>
> Are you sure that your package fso-foo really wants to Conflict: with
> and Replace: foo without also Providing: it?

I'd rather have it only Conflict:, but that places extra burden on the 
fso people.

> Although I don't think
> there is any reason why this is inherently illegitimate, it is certainly
> something of a fringe case and my first suspicion would be that this is
> a packaging bug which is just happening to tickle an opkg bug and/or
> misfeature.  I suspect opkg is taking a slightly harder line on this,
> deciding that lack of Provides: in this case must certainly be a
> packaging error, and proceeding as if that Provides: was present.  It's
> debatable whether this is a desirable thing for it to be doing but,
> irrespective of that, at least a part of the right answer is probably to
> fix the offending packages.

I have literally no clue about opkg internals, sorry.

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Phil Blundell]

On Wed, 2008-11-26 at 21:09 +0100, Koen Kooi wrote:
> I'd rather have it only Conflict:, but that places extra burden on the 
> fso people.

I must admit to being a bit baffled as to the effect that you (and/or
the fso people) are trying to produce.  Can you explain a bit more of
the background to this arrangement of packages?

p.

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 22:27, Phil Blundell wrote:
> On Wed, 2008-11-26 at 21:09 +0100, Koen Kooi wrote:
>> I'd rather have it only Conflict:, but that places extra burden on the
>> fso people.
>
> I must admit to being a bit baffled as to the effect that you (and/or
> the fso people) are trying to produce.  Can you explain a bit more of
> the background to this arrangement of packages?

I'm trying to clean up the 'mess' caused by the fso-packages, you'd have 
to ask Mickey what he actually wanted to achieve with the 
conflicts/replaces/provides dance.

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Sergey Lapin]

I just need to mention we have same kind of problems with mplayer vs
mplayer-maemo recipe,
when you try to put e.g. mencoder into IMAGE_INSTALL, mplayer-maemo
recipe is used instead of mplayer one.
Also, which is weird, I was able to reproduce this lots of times on
one my setup even with build from scratch,
and was unable to do so with my another setup.

All the best,
S.

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Denys Dmytriyenko]

On Wed, Nov 26, 2008 at 09:12:34PM +0300, Sergey Lapin wrote:
> I just need to mention we have same kind of problems with mplayer vs
> mplayer-maemo recipe,
> when you try to put e.g. mencoder into IMAGE_INSTALL, mplayer-maemo
> recipe is used instead of mplayer one.
> Also, which is weird, I was able to reproduce this lots of times on
> one my setup even with build from scratch,
> and was unable to do so with my another setup.

Sorry for my naive question, but why can't it be specified with

PREFERRED_PROVIDER_mplayer = "mplayer"

-- 
Denys

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 19:24, Denys Dmytriyenko wrote:
> On Wed, Nov 26, 2008 at 09:12:34PM +0300, Sergey Lapin wrote:
>> I just need to mention we have same kind of problems with mplayer vs
>> mplayer-maemo recipe,
>> when you try to put e.g. mencoder into IMAGE_INSTALL, mplayer-maemo
>> recipe is used instead of mplayer one.
>> Also, which is weird, I was able to reproduce this lots of times on
>> one my setup even with build from scratch,
>> and was unable to do so with my another setup.
>
> Sorry for my naive question, but why can't it be specified with
>
> PREFERRED_PROVIDER_mplayer = "mplayer"

That works at buildtime, opkg doesn't know about preferred_provider.

regards,

Koen

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Denys Dmytriyenko]

On Wed, Nov 26, 2008 at 07:33:29PM +0100, Koen Kooi wrote:
> On 26-11-08 19:24, Denys Dmytriyenko wrote:
>> On Wed, Nov 26, 2008 at 09:12:34PM +0300, Sergey Lapin wrote:
>>> I just need to mention we have same kind of problems with mplayer vs
>>> mplayer-maemo recipe,
>>> when you try to put e.g. mencoder into IMAGE_INSTALL, mplayer-maemo
>>> recipe is used instead of mplayer one.
>>> Also, which is weird, I was able to reproduce this lots of times on
>>> one my setup even with build from scratch,
>>> and was unable to do so with my another setup.
>>
>> Sorry for my naive question, but why can't it be specified with
>>
>> PREFERRED_PROVIDER_mplayer = "mplayer"
>
> That works at buildtime, opkg doesn't know about preferred_provider.

Thanks, that makes sense. Sergey's email above made me believe he was having 
build issues though.

-- 
Denys

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Phil Blundell]

On Wed, 2008-11-26 at 13:24 -0500, Denys Dmytriyenko wrote:
> On Wed, Nov 26, 2008 at 09:12:34PM +0300, Sergey Lapin wrote:
> > I just need to mention we have same kind of problems with mplayer vs
> > mplayer-maemo recipe,
> > when you try to put e.g. mencoder into IMAGE_INSTALL, mplayer-maemo
> > recipe is used instead of mplayer one.
> > Also, which is weird, I was able to reproduce this lots of times on
> > one my setup even with build from scratch,
> > and was unable to do so with my another setup.
> 
> Sorry for my naive question, but why can't it be specified with
> 
> PREFERRED_PROVIDER_mplayer = "mplayer"

That only sets the build-time preference.  It won't have any effect on
what happens at opkg run time if both binary packages are available.

p.

Re: preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 15:51, Koen Kooi wrote:
> Hi,
>
> Recently the FSO developers discovered that they can put
>
> RPROVIDES = "foo"
> RCONFLICTS = "foo"
>
> in their fso-foo recipe to have OE install fso-foo instead of foo in
> their fso-image. Great.
>
> The downside: people can't get 'foo' anymore in their image since
> 'fso-foo' will _always_ get choosen over 'foo'. Not so great.
>
> Normally it would be just a matter of putting PREFERRED_PROVIDER_foo =
> "foo" in the distro.conf, but that is not an option in this case, since
> when building 'fso-image' I actually want 'fso-foo' instead of 'foo'
>
> My proposal is:
>
> * remove the RPROVIDES, leave the RCONFLICTS

http://gitweb.openembedded.net/?p=openembedded.git;a=commitdiff;h=0457511ceb1dab4454a966b344ae1953ad7dfa94

regards,

Koen



> * put 'fso-foo' in IMAGE_INSTALL in fso-images instead of 'foo'
> * educate people using RPROVIDES, RCONFLICTS and RREPLACES in recipes
>
> objections?
>
> regards,
>
> Koen