Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/2] core/sdk: fix relative symlinks in generated tarball (branch yem/sdk)
Date: Sat, 22 Dec 2018 09:31:41 +0100	[thread overview]
Message-ID: <20181222083141.GU24194@scaer> (raw)
In-Reply-To: <CA+1k=2ZqHeLif6866SYX+hqRwatGiL1e-hZz-zdFuy_Ysfy+8g@mail.gmail.com>

Joel, Andreas, All,

On 2018-12-21 17:13 -0700, Joel Carlson spake thusly:
> On Fri, Dec 21, 2018 at 2:46 AM Andreas Naumann <dev@andin.de> wrote:
> > However, the check for symlinks pointing out of host/ showed to two
> > issues originating in install steps of iptables and eudev. Both create
> > links that point to system pathes.
> >
> > I have locally made POST_STAGING_HOOKS to fix that but that's probably a
> > non acceptable hack.
> 
> Would be hard to tell without seeing the actual change. ;-)
> That being said, this is probably something that would need to be
> fixed in iptables and eudev (patches submitted upstream), and then
> those patches added to buildroot to fix the issue.
> 
> So far I've submitted a patch to iptables here:
> http://patchwork.ozlabs.org/patch/1017739/
> 
> And a patch to buildroot to pull in a version of that here:
> https://patchwork.ozlabs.org/patch/1017740/
> 
> I've also submitted a pull request for eudev (and while typing this
> email it was already merged):
> https://github.com/gentoo/eudev/pull/165

I did nt see Thomas' reply to the iptables patch before I replied to
your eudev one. It turns out we basically said exactly the same thing:
this is not the correct solution.

If you do what you propose, then you can see that at runtime, on the
_target_, the symlinks will be wrong, bnecause they would be prefixed
with the DESTDIR, which is clearly not appropriate.

A better solution, in that case, wuld be to make relative symlinks
instead, but that is a little bit trickier.  A simple way to do that is
to use 'ln -r -s FILE LINK' but the -r option is not old enough to be
widely available on all distors, especially entreprise-grade distros.

An other approach, would be that we whietelist certain PATHs from our
SDK. Afterall, there are things we do not care about in the SDK. For
example, most executables in staging/{,usr/}{,s}bin are not needed. We
only really need libs and headers, so we could just ignore anything
that is not in staging/{lib,usr/lib,usr/include}/

I.e. the heuristic would become:

  if it is a symlink:
      if is not below staging/:
          check and fix it
      else if it is below staging/{lib,usr/lib,usr/include}:
          check and fix it
      else
          ignore it

I can try to look into fixing that in my series. Is enabling eudev
and/or iptables enough to echibit the problem?

Regards,
Yann E. MORIN.

> I'll submit a patch for eudev in buildroot to pull in that change once
> I see feedback on the iptables one. For it to work for me I needed to
> set AUTORECONF=YES on eudev, but I don't really understand
> autotools/automake stuff very well and I don't know if that is the
> right way to be doing things.
> -Joel

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-12-22  8:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 18:10 [Buildroot] [PATCH 0/2] core/sdk: fix relative symlinks in generated tarball (branch yem/sdk) Yann E. MORIN
2018-12-07 18:10 ` [Buildroot] [PATCH 1/2] core: make symlinks relative when preparing the SDK Yann E. MORIN
2018-12-07 19:35   ` Joel Carlson
2018-12-07 18:10 ` [Buildroot] [PATCH 2/2] core/sdk: don't mangle symlinks with '.' or '..' at start Yann E. MORIN
2018-12-07 19:39   ` Joel Carlson
2018-12-07 19:44     ` Yann E. MORIN
2018-12-21  9:46 ` [Buildroot] [PATCH 0/2] core/sdk: fix relative symlinks in generated tarball (branch yem/sdk) Andreas Naumann
2018-12-22  0:13   ` Joel Carlson
2018-12-22  8:31     ` Yann E. MORIN [this message]
2018-12-22 18:21       ` Joel Carlson
2018-12-22 18:54         ` Yann E. MORIN
2018-12-26 18:22         ` Trent Piepho
2018-12-22  8:32   ` Yann E. MORIN

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=20181222083141.GU24194@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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