Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Jussi Kukkonen <jussi.kukkonen@intel.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] sstate: Fix make_relative_symlink() for RSS
Date: Wed, 01 Feb 2017 12:53:57 +0000	[thread overview]
Message-ID: <1485953637.14144.27.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAHiDW_FdD4ms=zYtdsXWvy8gqSWzTrazC3dCkn_vKxtEL4L2oQ@mail.gmail.com>

On Wed, 2017-02-01 at 14:38 +0200, Jussi Kukkonen wrote:
> On 1 February 2017 at 14:00, Richard Purdie <richard.purdie@linuxfoun
> dation.org> wrote:
> > On Wed, 2017-02-01 at 13:44 +0200, Jussi Kukkonen wrote:
> > > On 1 February 2017 at 13:23, Richard Purdie <richard.purdie@linux
> > foun
> > > dation.org> wrote:
> > > > On Wed, 2017-02-01 at 12:03 +0200, Jussi Kukkonen wrote:
> > > > > Recipe-specific sysroots broke make_relative_symlink(), which
> > > > > turns absolute symlinks in sysroots into relative ones. Use
> > the
> > > > > difference between the (in-sysroot) paths to construct the
> > > > relative
> > > > > symlink.
> > > > >
> > > > > This fixes links in openssl-native, fontconfig-native and
> > bzip2-
> > > > > native.
> > > > >
> > > > > Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
> > > > > ---
> > > > >
> > > > > sstate is not an area I'm familiar with, please take a good
> > look.
> > > > >
> > > > > As far as I could see outputpath (based on state[2]) was
> > never
> > > > really
> > > > > needed so I did not use it in the new version.
> > > >
> > > > I don't think we can hardcode workdir into here as for tasks
> > like
> > > > do_deploy, this makes no sense. I think we removed most of the
> > > > absolute
> > > > links from the deploy tasks so we currently don't need this, at
> > > > least
> > > > in the common case but the sstate code is meant to be generic.
> > > >
> > > > I am wondering if we need to pass in anything at all, can't we
> > just
> > > > call relpath on the original path and turn it into a relative
> > one
> > > > directly without referencing it back to TMPDIR/WORKDIR?
> > > >
> > > The actual file path during do_populate_sysroot is something like
> > >   /mnt/extra-ssd/tmp/work/x86_64-linux/openssl-native/1.0.2j-
> > > r0/sysroot-destdir/mnt/extra-ssd/tmp/work/x86_64-linux/openssl-
> > > native/1.0.2j-r0/recipe-sysroot-native/usr/lib/ssl/certs
> > >
> > > and the link before make_relative_symlink() points to 
> > >   /mnt/extra-ssd/tmp/work/x86_64-linux/openssl-native/1.0.2j-
> > > r0/recipe-sysroot-native/etc/ssl/certs
> > >
> > > Assuming those are correct, I don't see how to do this without
> > > referencing WORKDIR or TMPDIR?
> > 
> > Good point, I knew I was missing something. How about passing in
> > walkroot/state[1] into the function, then you can subtract that
> > from
> > the actual file, then run relpath between the (srcpath - walkroot)
> > and
> > the link?
>
> Figuring out a sysroot-based path for srcpath is indeed possible (and
> nicer) using state[1] but then I have:
>   path /usr/lib/ssl/certs

Are you sure path isn't /mnt/extra-ssd/tmp/work/x86_64-linux/openssl-
native/1.0.2j-r0/recipe-sysroot-native/usr/lib/ssl/certs ?

>   link /mnt/extra-ssd/tmp/work/x86_64-linux/openssl-native/1.0.2j-
> r0/recipe-sysroot-native/etc/ssl/certs
> 
> Without knowledge of TMPDIR or WORKDIR, I don't see how I can turn
> link into anything like
>    ../../../etc/ssl/certs
> 
> Maybe I'm missing something?

I think you haven't realised path in this (native) case includes
$base_prefix which is the long path. I could well be missing something
too though...

Cheers,

Richard



  reply	other threads:[~2017-02-01 12:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 10:03 [PATCH] sstate: Fix make_relative_symlink() for RSS Jussi Kukkonen
2017-02-01 11:23 ` Richard Purdie
2017-02-01 11:44   ` Jussi Kukkonen
2017-02-01 12:00     ` Richard Purdie
2017-02-01 12:38       ` Jussi Kukkonen
2017-02-01 12:53         ` Richard Purdie [this message]
2017-02-01 13:27           ` Jussi Kukkonen

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=1485953637.14144.27.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=jussi.kukkonen@intel.com \
    --cc=openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox