[bitbake-devel] [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote

Khem Raj raj.khem at gmail.com
Mon Aug 8 16:25:20 UTC 2016


> On Aug 8, 2016, at 8:58 AM, Jérémy Rosen <jeremy.rosen at smile.fr> wrote:
> 
> 
> 
> On 08/08/2016 17:35, Khem Raj wrote:
>>> On Aug 8, 2016, at 4:24 AM, Jérémy Rosen <jeremy.rosen at smile.fr> wrote:
>>> 
>>> 
>>> On 08/08/2016 11:55, Richard Purdie wrote:
>>>> 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.
>>> To be honest, this is a real world problem I have on a regular basis...
>>> 
>>> The problem we have is that our customers want to keep an archive for (very) long term support and they test offline mode.
>>> 
>>> This problem means that we have to set all our SRC_URI to git SHA instead of the much more readable and easy to check git tags.
>>> 
>>> 
>>> you think to assume that a reference is a branch, but the real-life problem is when reference is a tag. Tag don't move so this is
>>> a case of locked configuration, but i'm not sure how to handle it.
>>> 
>>> Is there a way to have the best of both world somehow ?
>> Don’t use tags instead rely on SHA numbers in SRCREV and use
>> BB_GENERATE_MIRROR_TARBALLS like mentioned here
>> 
>> https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F
>> 
>> tags are floating types in git, you can not use them reliably.
>> You may tool in a method to automate updating the
>> recipes SRCREVs if you dont want to do it by hand.
>> 
>> That should help hopefully
> I know... but the fact that NO_NETWORK can't work if any git uses a tag seems... not what I would expect. Especially if the tag is available locally. I understand what you say, but I think it breaks the purpose of NO_NETWORK

There is an assumption here you are making, which is that tags are fixed in git which is not true. However when you use
tags in your recipe you want folks to use that tag and it could be moved/displaced under the hood and user would not notice
some tags like “last_good” “last_sane_build” are moving tags the are practiced. Tags are in same category as AUTOREV

BB_NO_NETWORK means you need to ensure that metadata can operate on disconnected snapshot which is not true for tags.

> 
> If a git reference is floating, then building twice won't produce the same result anyway... this sounds more like a QA problem to me than something that bitbake should enforce. But i'm really not a BB architect, it's just that this patch would solve one of our problem and i'd like to see if there is a way to do that without loosing other aspects of bitbake…
> 

We should be warning about this case as it does today and to make builds more predictable, this patch takes us in reverse direction.
otherwise soon folks have no idea what they are building every developer has his own snapshot think of supporting hundreds of developers
where you have no idea what combination they built to get into trouble that they are seeing. It turns into a nightmare very
quickly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20160808/c4a9c0f8/attachment-0002.sig>


More information about the bitbake-devel mailing list