All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348
Date: Tue, 13 Nov 2018 21:57:47 +0100	[thread overview]
Message-ID: <20181113215747.6960cbb3@windsurf> (raw)
In-Reply-To: <20181113202946.GH10271@scaer>

Hello,

On Tue, 13 Nov 2018 21:29:46 +0100, Yann E. MORIN wrote:

> > On my side, I have updated to Fedora 29, which ships tar 1.30, that we
> > consider as broken, and therefore now for everything single small build
> > that I do, I'm paying the price of building tar, which is super
> > annoying. This is especially annoying as tar 1.30 is only problematic
> > when *creating* tarballs of git-fetched packages, which clearly does
> > not happen at every build.  
> 
> Well, we only need host-tar and host-gzip when creating tarballs, not
> extracting them, correct? So, we could very well envision the fact that
> host-tar (and host-gzip) are only added to FOO_DOWNLOAD dependecies when
> FOO_SITE_METHOD == git (and they are needed, of course), no?

For host-tar, it's a bit complicated, because we have two conditions:

 - tar must be >= 1.27 for *extraction* to work properly.

 - tar must be < 1.30 for *creation* to work properly

So, if we add $(BR2_TAR_HOST_DEPENDENCY) to the package dependencies
only when FOO_SITE_METHOD = git, we would miss the case where it is
needed for extracting plain regular tarballs.

> > It would be truly horrible to also have to build our own gzip. Maybe we
> > need to somehow revisit our requirement that we need to have
> > reproducible tarballs for git-fetched packages ?  
> 
> I am ready to pay the price for reproducibility any time.

Well, for a "normal" build, I agree. When doing active BR development,
where one regularly builds from scratch small configurations, every
additional amount of time/stuff to build is annoying.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-11-13 20:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 15:33 [Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348 Marcin Niestroj
2018-11-09 20:57 ` Thomas Petazzoni
2018-11-09 21:06   ` Yann E. MORIN
2018-11-13 17:20     ` Marcin Niestrój
2018-11-13 17:32       ` Marcin Niestrój
2018-11-13 20:02       ` Thomas Petazzoni
2018-11-13 20:29         ` Yann E. MORIN
2018-11-13 20:57           ` Thomas Petazzoni [this message]
2018-11-13 23:54           ` Arnout Vandecappelle
2018-11-15 19:05             ` Yann E. MORIN
2018-11-16  8:35               ` Thomas Petazzoni
2018-11-20 18:50                 ` Yann E. MORIN
2018-11-20 23:47                   ` Arnout Vandecappelle
2018-11-21  7:13                     ` Peter Korsgaard
2018-11-13 21:34         ` Marcin Niestrój

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=20181113215747.6960cbb3@windsurf \
    --to=thomas.petazzoni@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.