From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Wolfgang Denk <wd@denx.de>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: specific version dependenciews
Date: Tue, 20 Mar 2012 14:49:56 +0000 [thread overview]
Message-ID: <1332254996.9740.97.camel@ted> (raw)
In-Reply-To: <20120320103520.22B00202A50@gemini.denx.de>
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
next prev parent reply other threads:[~2012-03-20 14:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1332254996.9740.97.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox