All of lore.kernel.org
 help / color / mirror / Atom feed
* specific version dependenciews - was: Linking two recipes
@ 2012-03-19 21:59 Wolfgang Denk
  2012-03-20  0:37 ` Richard Purdie
  2012-03-20  0:43 ` specific version dependenciews - was: Linking two recipes Denys Dmytriyenko
  0 siblings, 2 replies; 10+ messages in thread
From: Wolfgang Denk @ 2012-03-19 21:59 UTC (permalink / raw)
  To: openembedded-core

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews - was: Linking two recipes
  2012-03-19 21:59 specific version dependenciews - was: Linking two recipes Wolfgang Denk
@ 2012-03-20  0:37 ` Richard Purdie
  2012-03-20 10:35   ` specific version dependenciews Wolfgang Denk
  2012-03-20  0:43 ` specific version dependenciews - was: Linking two recipes Denys Dmytriyenko
  1 sibling, 1 reply; 10+ messages in thread
From: Richard Purdie @ 2012-03-20  0:37 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: openembedded-core

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews - was: Linking two recipes
  2012-03-19 21:59 specific version dependenciews - was: Linking two recipes Wolfgang Denk
  2012-03-20  0:37 ` Richard Purdie
@ 2012-03-20  0:43 ` Denys Dmytriyenko
  2012-03-20  9:25   ` Richard Purdie
  2012-03-20 11:33   ` Wolfgang Denk
  1 sibling, 2 replies; 10+ messages in thread
From: Denys Dmytriyenko @ 2012-03-20  0:43 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews - was: Linking two recipes
  2012-03-20  0:43 ` specific version dependenciews - was: Linking two recipes Denys Dmytriyenko
@ 2012-03-20  9:25   ` Richard Purdie
  2012-03-20 11:33   ` Wolfgang Denk
  1 sibling, 0 replies; 10+ messages in thread
From: Richard Purdie @ 2012-03-20  9:25 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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







^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews
  2012-03-20  0:37 ` Richard Purdie
@ 2012-03-20 10:35   ` Wolfgang Denk
  2012-03-20 14:49     ` Richard Purdie
  0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Denk @ 2012-03-20 10:35 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core

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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews - was: Linking two recipes
  2012-03-20  0:43 ` specific version dependenciews - was: Linking two recipes Denys Dmytriyenko
  2012-03-20  9:25   ` Richard Purdie
@ 2012-03-20 11:33   ` Wolfgang Denk
  2012-03-20 14:03     ` Henning Heinold
  1 sibling, 1 reply; 10+ messages in thread
From: Wolfgang Denk @ 2012-03-20 11:33 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer,
	Denys Dmytriyenko

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!



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews - was: Linking two recipes
  2012-03-20 11:33   ` Wolfgang Denk
@ 2012-03-20 14:03     ` Henning Heinold
  2012-03-20 16:15       ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Henning Heinold @ 2012-03-20 14:03 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews
  2012-03-20 10:35   ` specific version dependenciews Wolfgang Denk
@ 2012-03-20 14:49     ` Richard Purdie
  2012-03-20 16:06       ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Richard Purdie @ 2012-03-20 14:49 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: openembedded-core

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews
  2012-03-20 14:49     ` Richard Purdie
@ 2012-03-20 16:06       ` Wolfgang Denk
  0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Denk @ 2012-03-20 16:06 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: specific version dependenciews - was: Linking two recipes
  2012-03-20 14:03     ` Henning Heinold
@ 2012-03-20 16:15       ` Wolfgang Denk
  0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Denk @ 2012-03-20 16:15 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer, Henning Heinold

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_



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-03-20 16:24 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-19 21:59 specific version dependenciews - was: Linking two recipes Wolfgang Denk
2012-03-20  0:37 ` Richard Purdie
2012-03-20 10:35   ` specific version dependenciews Wolfgang Denk
2012-03-20 14:49     ` Richard Purdie
2012-03-20 16:06       ` Wolfgang Denk
2012-03-20  0:43 ` specific version dependenciews - was: Linking two recipes Denys Dmytriyenko
2012-03-20  9:25   ` Richard Purdie
2012-03-20 11:33   ` Wolfgang Denk
2012-03-20 14:03     ` Henning Heinold
2012-03-20 16:15       ` Wolfgang Denk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.