public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: <bitbake-devel@lists.openembedded.org>
Cc: <isar-users@googlegroups.com>
Subject: Re: [PATCH] fetch/git: add support for disabling shared clones on unpack
Date: Tue, 12 Dec 2017 15:49:43 +0100	[thread overview]
Message-ID: <20171212154943.55b0e2eb@mmd1pvb1c.ad001.siemens.net> (raw)
In-Reply-To: <20171212144443.30618-1-henning.schild@siemens.com>

We actually ran into that issue on a build system called Isar.

https://github.com/ilbers/isar

This build system executes some tasks in a chroot. In this chroot a
"shared" clone will not work because it expects its "alternate" to be
at the very same location it was outside the chroot. We considered
several hacks in Isar
- patching the alternates before and after chroot
- mounting the "alternate" to the exact location in chroot
None of this is really nice, so we decided to try and do something
about it upstream.

regards,
Henning

Am Tue, 12 Dec 2017 15:44:43 +0100
schrieb Henning Schild <henning.schild@siemens.com>:

> By default the unpacker will create a "shared" clone when cloning from
> the DL_DIR to the WORKDIR. This patch introduces an option to control
> that behaviour. Probably something that hardly anyone would want to
> do.
> 
> Imagine some recipe steps are executed in a namespace that is
> different from the one your downloader and unpacker ran in. (chroot)
> Because a "shared" clone has an absolute reference to its "alternate"
> you now have to make that "alternate" visible in that new namespace
> (chroot) at the exact place.
> 
> With this patch you can unpack "noshared" and get a stand-alone copy.
> This copy will also work if the "alternate" is not visible or
> existant.
> 
> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> ---
>  lib/bb/fetch2/git.py | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/bb/fetch2/git.py b/lib/bb/fetch2/git.py
> index 5ef8cd69..30b88c83 100644
> --- a/lib/bb/fetch2/git.py
> +++ b/lib/bb/fetch2/git.py
> @@ -53,6 +53,13 @@ Supported SRC_URI options are:
>     For local git:// urls to use the current branch HEAD as the
> revision for use with AUTOREV. Implies nobranch.
>  
> +- noshared
> +   When unpacking do not clone with the parameter "--shared". This
> option will
> +   allow the unpacked copy to work stand-alone i.e. if your recipe
> runs in a
> +   chroot where the "alternate" can not be found. Setting this will
> increase
> +   the unpack-time and the disk-usage.
> +   The default is "0", set noshared=1 if needed.
> +
>  """
>  
>  #Copyright (C) 2005 Richard Purdie
> @@ -159,6 +166,8 @@ class Git(FetchMethod):
>  
>          ud.nobranch = ud.parm.get("nobranch","0") == "1"
>  
> +        ud.noshared = ud.parm.get("noshared","0") == "1"
> +
>          # usehead implies nobranch
>          ud.usehead = ud.parm.get("usehead","0") == "1"
>          if ud.usehead:
> @@ -176,7 +185,9 @@ class Git(FetchMethod):
>          if len(branches) != len(ud.names):
>              raise bb.fetch2.ParameterError("The number of name and
> branch parameters is not balanced", ud.url) 
> -        ud.cloneflags = "-s -n"
> +        cloneflags = "-n"
> +        if not ud.noshared:
> +            cloneflags += " -s"
>          if ud.bareclone:
>              ud.cloneflags += " --mirror"
>  


  reply	other threads:[~2017-12-12 14:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 14:44 Henning Schild
2017-12-12 14:49 ` Henning Schild [this message]
2017-12-12 15:01 ` Henning Schild
2017-12-12 15:12 ` [PATCH v2] " Henning Schild
2018-02-12  7:40   ` Jan Kiszka
2017-12-12 15:14 ` [PATCH] " Henning Schild
2017-12-20 16:42 Henning Schild
2017-12-20 16:44 ` Henning Schild
2017-12-20 16:45 ` Henning Schild
2018-01-30 12:18   ` Henning Schild

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=20171212154943.55b0e2eb@mmd1pvb1c.ad001.siemens.net \
    --to=henning.schild@siemens.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=isar-users@googlegroups.com \
    /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