[OE-core] [PATCH 1/1] sstate.bbclass: Don't create symlinks, download to the correct location

[Christopher Larson]

On Mon, May 23, 2016 at 2:57 PM, Randy Witt <randy.e.witt at linux.intel.com>
wrote:

> Previously the sstate was all downloaded to the same directory and then
> symlinks were added in the directories that pointed to the siginfo and
> sstate in the parent directory.
>
> This change makes it so that now the files are just downloaded to the
> correct location without the need for symlinks.
>
> Signed-off-by: Randy Witt <randy.e.witt at linux.intel.com>
> ---
>  meta/classes/sstate.bbclass | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 22ce1ee..6d5411f 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -623,10 +623,10 @@ def pstaging_fetch(sstatefetch, sstatepkg, d):
>
>      # Try a fetch from the sstate mirror, if it fails just return and
>      # we will build the package
> -    uris = ['file://{0}'.format(sstatefetch),
> -            'file://{0}.siginfo'.format(sstatefetch)]
> +    uris = ['file://{0};downloadfilename={1}'.format(sstatefetch,
> sstatefetch),
> +
> 'file://{0}.siginfo;downloadfilename={1}.siginfo'.format(sstatefetch,
> sstatefetch)]
>      if bb.utils.to_boolean(d.getVar("SSTATE_VERIFY_SIG", True), False):
> -        uris += ['file://{0}.sig'.format(sstatefetch)]
> +        uris +=
> ['file://{0}.sig;downloadfilename={1}.sig'.format(sstatefetch, sstatefetch)]
>

The use of {1} and passing the argument a second time is not needed. This
isn't the old style formatting with %s. Just use the existing argument:

    file://{0};downloadfilename={0}'.format(sstatefetch)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160523/c8631f48/attachment-0002.html>