From: Tobias Hagelborn <tobias.hagelborn@axis.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
"bitbake-devel@lists.openembedded.org"
<bitbake-devel@lists.openembedded.org>
Subject: Re: [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote
Date: Mon, 8 Aug 2016 12:54:31 +0000 [thread overview]
Message-ID: <1470660871158.8123@axis.com> (raw)
In-Reply-To: <1470650127.8166.40.camel@linuxfoundation.org>
Hi Richard,
I think I understand your concern. This patch takes whatever is available locally and that means it is a side-effect compared to not setting BB_NO_NETWORK. Something the user might not expect.
I don't know if you would accept the use of a new flag that the user can set to agree with this side effect.
Something along the lines of "FORCE_LOCAL_TAGS".
Then the user would have given some consent on that side-affect.
We think it is still very useful to us to be able to build locally with whatever you have fetched in cases where no NW is available and you basically know that few/no tags have moved.
Regards
Tobias
________________________________________
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Sent: Monday, August 8, 2016 11:55 AM
To: Tobias Hagelborn; bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote
On Mon, 2016-08-08 at 08:34 +0000, Tobias Hagelborn wrote:
> Change made to enable building offline also with git tag references
> in SRC_URI.
>
> If BB_NO_NETWORK is set, fallback to search for tags and revisions
> in local DL_DIR / GITDIR in order to avoid network access.
I'm not sure I agree with this since you'd get different build results
depending on whether BB_NO_NETWORK is set or not.
I think if BB_NO_NETWORK is set, its reasonable to assume that the
configuration should be locked down and that BB_NO_NETWORK should not
have other side effects like this.
It would also make it very hard to detect unlocked configurations
during testing which currently are quite easily identified.
Cheers,
Richard
next prev parent reply other threads:[~2016-08-08 12:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 8:34 [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote Tobias Hagelborn
2016-08-08 9:55 ` Richard Purdie
2016-08-08 11:24 ` Jérémy Rosen
2016-08-08 15:35 ` Khem Raj
2016-08-08 15:58 ` Jérémy Rosen
2016-08-08 16:25 ` Khem Raj
2016-08-08 16:39 ` Olof Johansson
2016-08-08 17:22 ` Khem Raj
2016-08-09 9:36 ` Olof Johansson
2016-08-09 10:50 ` Barros Pena, Belen
2016-08-09 14:34 ` Khem Raj
2016-08-09 15:09 ` Olof Johansson
2016-08-09 15:54 ` Khem Raj
2016-08-09 16:26 ` Olof Johansson
2016-08-10 8:54 ` Richard Purdie
2016-08-09 3:22 ` Paul Eggleton
2016-08-09 8:15 ` Jérémy Rosen
2016-08-09 9:49 ` Tobias Hagelborn
2016-08-08 12:54 ` Tobias Hagelborn [this message]
[not found] <801c8b3c-a6f7-6b96-a527-d61c70a4a574@smile.fr>
2016-08-10 8:28 ` Jérémy Rosen
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=1470660871158.8123@axis.com \
--to=tobias.hagelborn@axis.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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 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.