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:00:56 +0000 [thread overview]
Message-ID: <1485950456.14144.25.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAHiDW_GosUv9rS2c5yZXvWgReno1rorTk4cR5J00+XZPb9wytg@mail.gmail.com>
On Wed, 2017-02-01 at 13:44 +0200, Jussi Kukkonen wrote:
> On 1 February 2017 at 13:23, Richard Purdie <richard.purdie@linuxfoun
> 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?
Cheers,
Richard
next prev parent reply other threads:[~2017-02-01 12:01 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 [this message]
2017-02-01 12:38 ` Jussi Kukkonen
2017-02-01 12:53 ` Richard Purdie
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=1485950456.14144.25.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