Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] Added local directory as source of kernel code
Date: Thu, 8 Nov 2018 11:41:25 +0100	[thread overview]
Message-ID: <20181108114125.549ff7c6@windsurf> (raw)
In-Reply-To: <20181107185226.GB4702@scaer>

Hello Yann,

On Wed, 7 Nov 2018 19:52:26 +0100, Yann E. MORIN wrote:

> > Alternatively, maybe we should decide that linux and u-boot are special
> > packages, and just like for those packages we support fetching from
> > custom tarballs and custom Git repositories, we should support fetching
> > from custom local directories (this is what your patch implements, but
> > until now, we have resisted going into this direction).  
> 
> I would say we should not go that route, otherwise it would be difficult
> to resist adding yet more exceptions, for people that have local "forks"
> for some packages. And then it becomes a nightmare to maintain.

Well, there are a few packages that we do consider "special", because
for them we provide the possibility of specifying a custom tarball, a
custom git/hg repository. So we do recognize that some packages are
special, and we have added special logic to them.

So our argument "we don't want to go down that route as it would be a
nightmare to have that for all packages" already doesn't hold very
well: we have some special logic for custom fetching in packages like
linux, uboot or barebox, and we have not accepted to propagate such
logic to other less special packages.

So, we have already identified some special packages for which it makes
sense to provide more flexibility on how to fetch the source code, and
it that sense, providing the option to use a local folder would seem
quite logical.

Don't get me wrong: I am not pushing hard to this patch to be merged. I
just want to point out that the argument we use to reject the patch is
not very solid. And I don't blame you specifically, because I used the
exact same argument :-)

Best regards,

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

  parent reply	other threads:[~2018-11-08 10:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-07 10:06 [Buildroot] [PATCH 1/1] Added local directory as source of kernel code Nicolas Carrier
2018-11-07 13:57 ` Matthew Weber
2018-11-07 14:40   ` Nicolas Carrier
2018-11-07 16:44     ` Thomas Petazzoni
2018-11-07 17:08       ` Nicolas Carrier
2018-11-07 18:52       ` Yann E. MORIN
2018-11-07 21:26         ` Arnout Vandecappelle
2018-11-07 22:32           ` Yann E. MORIN
2018-11-08 10:07             ` Nicolas Carrier
2018-11-08 10:42           ` Thomas Petazzoni
2018-11-08 10:41         ` Thomas Petazzoni [this message]
2018-11-07 20:25 ` Arnout Vandecappelle
2018-11-09  7:37   ` Nicolas Carrier

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=20181108114125.549ff7c6@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox