From: Trent Piepho <tpiepho@impinj.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/2] core/sdk: fix relative symlinks in generated tarball (branch yem/sdk)
Date: Wed, 26 Dec 2018 18:22:26 +0000 [thread overview]
Message-ID: <1545848546.7501.7.camel@impinj.com> (raw)
In-Reply-To: <CA+1k=2ay7v0G0pjwB4PTTR-6mH3_FueDiFi8D3rhbcZa35zq+g@mail.gmail.com>
On Sat, 2018-12-22 at 11:21 -0700, Joel Carlson wrote:
> On Sat, Dec 22, 2018 at 1:31 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >
> >
> > 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}/
With per-package staging, could this be done before the per-package
staging areas are combined? The idea would be to reduce differences
between the stage in buildroot and the stage when using an SDK. Every
difference is a possible source of problems, even if it is something
that we are not supposed to care about.
Could this be taken further, and everything not in the stage whitelist
be deleted? It would be nice if the SDK were smaller.
next prev parent reply other threads:[~2018-12-26 18:22 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
2018-12-22 18:21 ` Joel Carlson
2018-12-22 18:54 ` Yann E. MORIN
2018-12-26 18:22 ` Trent Piepho [this message]
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=1545848546.7501.7.camel@impinj.com \
--to=tpiepho@impinj.com \
--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