All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Lock <joshua.lock@intel.com>
To: yocto@yoctoproject.org
Subject: Re: version problems about SDK
Date: Mon, 13 Dec 2010 12:01:03 +0000	[thread overview]
Message-ID: <1292241663.2485.4.camel@scimitar> (raw)
In-Reply-To: <9AFCD584B0B67B48AE8D8585BE30BA950465C55F@orsmsx504.amr.corp.intel.com>

On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
> Tian, Kevin wrote:
> >> From: Ke, Liping
> >> Sent: Monday, December 13, 2010 2:53 PM
> >> 
> >> Hi, Jessica & Josh
> >> 
> >> When we are trying to run installer script on lianhao's x86_64
> >> machine, we found if the images are build in two days, according to
> >> current version naming convention, some of the packages will be
> >> installed to /opt/poky/0.9+snapshot-20101210, some will be to
> >> /opt/poky/0.9+snapshot-20101210. 
> >> It will cause problem since we need to know the exact version number
> >> before installing and searching some files (environment script file,
> >> etc). And the same releases of packages belong to different version
> >> (just the build date is not in the same day) seems very strange and
> >> hard to handle for us?  
> >> 
> > 
> > I think Josh has laid down the base for multiple version SDK support.
> > The only problem is: 
> > 
> > SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
> > 
> > which obviously is not what we want. We need a similar variable like
> > SDK_VERSION, which is incremented only when SDK team thinks there's a
> > need for a new version release or 
> > else it keeps same in the life cycle of current version.

I disagree, I think it's definitely useful to know which distribution
version your SDK is built against. In fact as the SDK components are
generated from the distro metadata introducing an extra variable seems a
little superfluous and just increases the number of things which need to
be changed for a release.

Also note the DATE element is only included in the DISTRO_VERSION for
development snapshots.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

  reply	other threads:[~2010-12-13 12:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-13  6:52 version problems about SDK Ke, Liping
2010-12-13  6:59 ` Tian, Kevin
2010-12-13  7:53   ` Zhang, Jessica
2010-12-13 12:01     ` Joshua Lock [this message]
2010-12-13 12:22       ` Tian, Kevin
2010-12-13 22:33       ` Zhang, Jessica

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=1292241663.2485.4.camel@scimitar \
    --to=joshua.lock@intel.com \
    --cc=yocto@yoctoproject.org \
    /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 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.