specific version dependenciews - was: Linking two recipes

specific version dependenciews - was: Linking two recipes

[Wolfgang Denk]

Dear Richard,

In message <1332192150.9740.72.camel@ted> you wrote:
> On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > Hello,
> > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > requires a lib.so file and init.h file which are installed by Recipe
> > A.
...
> recipe B needs to do:
> 
> DEPENDS += "recipeA"

I have a similar, but more complicated requirement which I don;t know
how to implement (if this is possible at all):

Some MACHINEs require a package A (some library), but in specific
versions: say machine X needs version A-1.2, while machine Y needs
version A-1.5.

Package A itself depends on another package B (another library).

The problem is, that different versions of A require specific versions
of B.  For example, to build A-1.2 we must use B-4.5, but to build
A-1.5 we must use B-8.2.

I am aware that I can describe the dependencies at the top leven,
stating for example that machine X needs A-1.2 and B-4.5, while
machine Y needs A-1.5 and B-8.2.

However, this seems clumsy, as the version depency A->B is something
that is only defined by the implementation of A, and I would like to
keep it encapsulated at this level.


Is there a clever way to describe such a multi-level dependency chain?

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
As in certain cults it is possible to kill a process if you know  its
true name.                      -- Ken Thompson and Dennis M. Ritchie

Re: specific version dependenciews - was: Linking two recipes

[Richard Purdie]

On Mon, 2012-03-19 at 22:59 +0100, Wolfgang Denk wrote:
> In message <1332192150.9740.72.camel@ted> you wrote:
> > On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > > Hello,
> > > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > > requires a lib.so file and init.h file which are installed by Recipe
> > > A.
> ...
> > recipe B needs to do:
> > 
> > DEPENDS += "recipeA"
> 
> I have a similar, but more complicated requirement which I don;t know
> how to implement (if this is possible at all):
> 
> Some MACHINEs require a package A (some library), but in specific
> versions: say machine X needs version A-1.2, while machine Y needs
> version A-1.5.
> 
> Package A itself depends on another package B (another library).
> 
> The problem is, that different versions of A require specific versions
> of B.  For example, to build A-1.2 we must use B-4.5, but to build
> A-1.5 we must use B-8.2.
> 
> I am aware that I can describe the dependencies at the top leven,
> stating for example that machine X needs A-1.2 and B-4.5, while
> machine Y needs A-1.5 and B-8.2.
> 
> However, this seems clumsy, as the version depency A->B is something
> that is only defined by the implementation of A, and I would like to
> keep it encapsulated at this level.
> 
> 
> Is there a clever way to describe such a multi-level dependency chain?

If you mark A and B as machine specific, the system should be able to
cope with the problem and set the preferred versions at the machine
level.

Cheers,

Richard

Re: specific version dependenciews

[Wolfgang Denk]

Dear Richard,

In message <1332203843.9740.76.camel@ted> you wrote:
...
> > Some MACHINEs require a package A (some library), but in specific
> > versions: say machine X needs version A-1.2, while machine Y needs
> > version A-1.5.
> > 
> > Package A itself depends on another package B (another library).
> > 
> > The problem is, that different versions of A require specific versions
> > of B.  For example, to build A-1.2 we must use B-4.5, but to build
> > A-1.5 we must use B-8.2.
> > 
> > I am aware that I can describe the dependencies at the top leven,
> > stating for example that machine X needs A-1.2 and B-4.5, while
> > machine Y needs A-1.5 and B-8.2.
> > 
> > However, this seems clumsy, as the version depency A->B is something
> > that is only defined by the implementation of A, and I would like to
> > keep it encapsulated at this level.
> > 
> > 
> > Is there a clever way to describe such a multi-level dependency chain?
> 
> If you mark A and B as machine specific, the system should be able to
> cope with the problem and set the preferred versions at the machine
> level.

I'm sorry, but I don't understand what you mean.

How do I mark a package as machine specific?

And would setting "the preferred versions at the machine level" not be
exactly what I am trying to avoid?

I don't want to make the machine descriptions aware of any version
dependencies between A and B.  I would like to put this information
into the description of A, so that when a specific version of A gets
built, automatically the matching version of B will be chosen.

Can this be done?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is easier to change the specification to fit the program than vice
versa.

Re: specific version dependenciews

[Richard Purdie]

On Tue, 2012-03-20 at 11:35 +0100, Wolfgang Denk wrote:
> Dear Richard,
> 
> In message <1332203843.9740.76.camel@ted> you wrote:
> ...
> > > Some MACHINEs require a package A (some library), but in specific
> > > versions: say machine X needs version A-1.2, while machine Y needs
> > > version A-1.5.
> > > 
> > > Package A itself depends on another package B (another library).
> > > 
> > > The problem is, that different versions of A require specific versions
> > > of B.  For example, to build A-1.2 we must use B-4.5, but to build
> > > A-1.5 we must use B-8.2.
> > > 
> > > I am aware that I can describe the dependencies at the top leven,
> > > stating for example that machine X needs A-1.2 and B-4.5, while
> > > machine Y needs A-1.5 and B-8.2.
> > > 
> > > However, this seems clumsy, as the version depency A->B is something
> > > that is only defined by the implementation of A, and I would like to
> > > keep it encapsulated at this level.
> > > 
> > > 
> > > Is there a clever way to describe such a multi-level dependency chain?
> > 
> > If you mark A and B as machine specific, the system should be able to
> > cope with the problem and set the preferred versions at the machine
> > level.
> 
> I'm sorry, but I don't understand what you mean.
> 
> How do I mark a package as machine specific?

PACKAGE_ARCH = "${MACHINE_ARCH}"

> And would setting "the preferred versions at the machine level" not be
> exactly what I am trying to avoid?
> 
> I don't want to make the machine descriptions aware of any version
> dependencies between A and B.  I would like to put this information
> into the description of A, so that when a specific version of A gets
> built, automatically the matching version of B will be chosen.
> 
> Can this be done?

You could write the dependency A in the form:

DEPENDS = "B-1.2"

where 1.2 is version of B you want. This has been known to work in the
past but isn't well supported/well tested. It can work since B PROVIDES
"${PN}-${PV}".

Cheers,

Richard

Re: specific version dependenciews

[Wolfgang Denk]

Dear Richard,

In message <1332254996.9740.97.camel@ted> you wrote:
>
> > How do I mark a package as machine specific?
> 
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> 
> > And would setting "the preferred versions at the machine level" not be
> > exactly what I am trying to avoid?
> > 
> > I don't want to make the machine descriptions aware of any version
> > dependencies between A and B.  I would like to put this information
> > into the description of A, so that when a specific version of A gets
> > built, automatically the matching version of B will be chosen.
> > 
> > Can this be done?
> 
> You could write the dependency A in the form:
> 
> DEPENDS = "B-1.2"
> 
> where 1.2 is version of B you want. This has been known to work in the
> past but isn't well supported/well tested. It can work since B PROVIDES
> "${PN}-${PV}".

We will try this.

Thanks a lot!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Everybody is talking about the  weather  but  nobody  does  anything
about it."                                               - Mark Twain

Re: specific version dependenciews - was: Linking two recipes

[Denys Dmytriyenko]

On Mon, Mar 19, 2012 at 10:59:34PM +0100, Wolfgang Denk wrote:
> Dear Richard,
> 
> In message <1332192150.9740.72.camel@ted> you wrote:
> > On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > > Hello,
> > > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > > requires a lib.so file and init.h file which are installed by Recipe
> > > A.
> ...
> > recipe B needs to do:
> > 
> > DEPENDS += "recipeA"
> 
> I have a similar, but more complicated requirement which I don;t know
> how to implement (if this is possible at all):
> 
> Some MACHINEs require a package A (some library), but in specific
> versions: say machine X needs version A-1.2, while machine Y needs
> version A-1.5.
> 
> Package A itself depends on another package B (another library).
> 
> The problem is, that different versions of A require specific versions
> of B.  For example, to build A-1.2 we must use B-4.5, but to build
> A-1.5 we must use B-8.2.
> 
> I am aware that I can describe the dependencies at the top leven,
> stating for example that machine X needs A-1.2 and B-4.5, while
> machine Y needs A-1.5 and B-8.2.
> 
> However, this seems clumsy, as the version depency A->B is something
> that is only defined by the implementation of A, and I would like to
> keep it encapsulated at this level.
> 
> 
> Is there a clever way to describe such a multi-level dependency chain?

Will this help? See line #4 in the first example and lines #30-31 in second:

http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/gnutls/gnutls.inc#n4
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-nodm-init/xserver-nodm-init_2.0.bb#n30

There are some caveats with that notation, IIRC...

-- 
Denys

Re: specific version dependenciews - was: Linking two recipes

[Richard Purdie]

On Mon, 2012-03-19 at 20:43 -0400, Denys Dmytriyenko wrote:
> On Mon, Mar 19, 2012 at 10:59:34PM +0100, Wolfgang Denk wrote:
> > Dear Richard,
> > 
> > In message <1332192150.9740.72.camel@ted> you wrote:
> > > On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > > > Hello,
> > > > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > > > requires a lib.so file and init.h file which are installed by Recipe
> > > > A.
> > ...
> > > recipe B needs to do:
> > > 
> > > DEPENDS += "recipeA"
> > 
> > I have a similar, but more complicated requirement which I don;t know
> > how to implement (if this is possible at all):
> > 
> > Some MACHINEs require a package A (some library), but in specific
> > versions: say machine X needs version A-1.2, while machine Y needs
> > version A-1.5.
> > 
> > Package A itself depends on another package B (another library).
> > 
> > The problem is, that different versions of A require specific versions
> > of B.  For example, to build A-1.2 we must use B-4.5, but to build
> > A-1.5 we must use B-8.2.
> > 
> > I am aware that I can describe the dependencies at the top leven,
> > stating for example that machine X needs A-1.2 and B-4.5, while
> > machine Y needs A-1.5 and B-8.2.
> > 
> > However, this seems clumsy, as the version depency A->B is something
> > that is only defined by the implementation of A, and I would like to
> > keep it encapsulated at this level.
> > 
> > 
> > Is there a clever way to describe such a multi-level dependency chain?
> 
> Will this help? See line #4 in the first example and lines #30-31 in second:
> 
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/gnutls/gnutls.inc#n4
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-nodm-init/xserver-nodm-init_2.0.bb#n30
> 
> There are some caveats with that notation, IIRC...

The RDEPENDS version will work. The parser will tolerate the entry in
DEPENDS but as the code stands today, ignore it since the code has never
been implemented.

Cheers,

Richard

Re: specific version dependenciews - was: Linking two recipes

[Wolfgang Denk]

Dear Denys,

In message <20120320004345.GG15554@denix.org> you wrote:
>
> > Is there a clever way to describe such a multi-level dependency chain?
> 
> Will this help? See line #4 in the first example and lines #30-31 in second:
> 
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/gnutls/gnutls.inc#n4
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-nodm-init/xserver-nodm-init_2.0.bb#n30

Yes, this looks indeed interesting.

Is there also away to ask for a specific package version, i. e.
instead of "libgcrypt (>= 1.4.2)" something like "libgcrypt (= 1.4.2)"
or "libgcrypt-1.4.2" or such?

> There are some caveats with that notation, IIRC...

What would these be?  Is there any documentation about such details?
I searched the bitbake, poky and yocto docs but could not find it...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Our OS who art in CPU, UNIX be thy name.
Thy programs run, thy syscalls done,
In kernel as it is in user!

Re: specific version dependenciews - was: Linking two recipes

[Henning Heinold]

On Tue, Mar 20, 2012 at 12:33:48PM +0100, Wolfgang Denk wrote:
> What would these be?  Is there any documentation about such details?
> I searched the bitbake, poky and yocto docs but could not find it...
> 
> Best regards,
> 
> Wolfgang Denk
> 

Hi Wolfgang,

we do not support version bounding in the recipes directly. You might have to
go with the PREFFRED_VERSION prefix for the recipes in the machine file.

Bye Henning

Re: specific version dependenciews - was: Linking two recipes

[Wolfgang Denk]

Dear Henning,

In message <20120320140310.GA14747@rhein.zuhause.netz> you wrote:
>
> we do not support version bounding in the recipes directly. You might have to
> go with the PREFFRED_VERSION prefix for the recipes in the machine file.

Thanks!


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You got to learn three things. What's  real,  what's  not  real,  and
what's the difference."           - Terry Pratchett, _Witches Abroad_