public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Alexander Smirnov <asmirnov@ilbers.de>
To: Henning Schild <henning.schild@siemens.com>
Cc: isar-users@googlegroups.com
Subject: Re: [PATCH v3 4/4] dpkg-base: Update git alternates
Date: Tue, 12 Dec 2017 15:30:00 +0300	[thread overview]
Message-ID: <13a670ad-aabf-0145-57a3-28c38338f970@ilbers.de> (raw)
In-Reply-To: <20171212124936.2329ba8d@md1pvb1c>



On 12/12/2017 02:49 PM, Henning Schild wrote:
> Am Mon, 11 Dec 2017 22:45:15 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> On 12/11/2017 08:56 PM, Henning Schild wrote:
>>> Well i thought about this again. This is a very nasty workaround
>>> for a problem this actually is in bitbake.
>>
>> That's an attempt to solve here and now git-3.0 issue reported by
>> Christian. So if in general it's not critical problem for now, I
>> could drop this series.
>>
>>>
>>> https://github.com/openembedded/bitbake/blob/ebce92bf8d71f8a6e8af1c6cf6ba335faf9d67c8/lib/bb/fetch2/git.py#L179
>>>
>>> That problem should be fixed in bitbake, if they accept patches. The
>>> "-s" needs to depend on some condition.
>>>    
>>
>> I'm not sure that this is the best solution. The main idea of using
>> '-s' was to avoid unnecessary copying of git repos within one build,
>> it costs disk space and extra time for copying (for example linux.git
>> is about 1GB). So usage of '-s' is quite reasonable here.
> 
> I know why it is there, all i am saying it should maybe not be there
> unconditionally. We could probably try and fix that upstrem and
> introduce BB_GIT_SHARED or a new param "shared".
> 
> And now you could say
> BB_GIT_SHARED=0
> SRC_URI=git:// ....git
> or
> SRC_URI=git:// ....git;shared=0

I like this one, I've already investigated supported parameters for git 
protocol, there are lot of them. So extra new one should not be a 
problem :-)

> 
> Let me know what you think about that idea and i will prepare patches.

So, if it covers your use case and you could prepare the patch, this 
would be great :-)

Alex

> If they get merged we could cherry-pick them into Isar and forget about
> the alternate-patching.
> 
> We could also agree that "shared" is an important feature we want in
> Isar, in that case the alternates should get patched. And we need an
> updated version of the proposed patch.
> Thinking about that ... again ;) This is would i would now vote for.
> 
>> Another solution could be deprecate 'downloads' directory and fetch
>> gits directly to package WORKDIR.
> 
> I think having the downloads dir might eventually help with the
> reproducible builds.
> 
>>
>>> For Isar i would tell people to fetch tarballs from git servers and
>>> avoid git://.
>>
>> This should not be the requirement, because it limits Isar
>> application area. Not all git repo could be fetched as tarball.
> 
> Agreed, i am just talking about temporary workarounds until we have a
> solution. Fetching with git is something that, to me, does not sound
> like a high prio feature.
> 
> Henning
> 
>> Alex
>>
>>>
>>> Henning
>>>
>>> Am Mon, 27 Nov 2017 01:00:25 +0300
>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>    
>>>> Update git alternates to work in buildchroot.
>>>>
>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>>> ---
>>>>    meta/classes/dpkg-base.bbclass | 12 ++++++++++++
>>>>    1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/meta/classes/dpkg-base.bbclass
>>>> b/meta/classes/dpkg-base.bbclass index 5d7f8b6..6a78a26 100644
>>>> --- a/meta/classes/dpkg-base.bbclass
>>>> +++ b/meta/classes/dpkg-base.bbclass
>>>> @@ -18,12 +18,24 @@ dpkg_runbuild() {
>>>>    
>>>>    # Wrap the function dpkg_runbuild with the bind mount for
>>>> buildroot do_build() {
>>>> +    if [ -d ${WORKDIR}/git/.git ]; then
>>>> +        OBJ_PATH=$(cat
>>>> ${WORKDIR}/git/.git/objects/info/alternates)
>>>> +        REPO_PATH=$(dirname $OBJ_PATH)
>>>> +        REPO_NAME=$(basename $REPO_PATH)
>>>> +        echo "/git/$REPO_NAME/objects" >
>>>> ${WORKDIR}/git/.git/objects/info/alternates
>>>> +    fi
>>>> +
>>>>        mkdir -p ${BUILDROOT}
>>>>        sudo mount --bind ${WORKDIR} ${BUILDROOT}
>>>>        _do_build_cleanup() {
>>>>            ret=$?
>>>>            sudo umount ${BUILDROOT} 2>/dev/null || true
>>>>            sudo rmdir ${BUILDROOT} 2>/dev/null || true
>>>> +
>>>> +        if [ -d ${WORKDIR}/git/.git ]; then
>>>> +            echo $OBJ_PATH >
>>>> ${WORKDIR}/git/.git/objects/info/alternates
>>>> +        fi
>>>> +
>>>>            (exit $ret) || sudo umount ${BUILDCHROOT_DIR}/git
>>>>            (exit $ret) || bb_exit_handler
>>>>        }
>>>    
>>
>

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

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 22:00 [PATCH v3 0/4] Buildchroot prepare/cleanup Alexander Smirnov
2017-11-26 22:00 ` [PATCH v3 1/4] dpkg-base: Fix buildchroot dependency Alexander Smirnov
2017-11-26 22:00 ` [PATCH v3 2/4] image: Add do_rootfs template to image class Alexander Smirnov
2017-11-26 22:00 ` [PATCH v3 3/4] buildchroot: Add prepare and cleanup tasks Alexander Smirnov
2017-11-26 22:00 ` [PATCH v3 4/4] dpkg-base: Update git alternates Alexander Smirnov
2017-12-11 17:56   ` Henning Schild
2017-12-11 19:45     ` Alexander Smirnov
2017-12-12 11:49       ` Henning Schild
2017-12-12 12:30         ` Alexander Smirnov [this message]
2017-12-11 18:03   ` Jan Kiszka
2017-12-11 19:49     ` Alexander Smirnov

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=13a670ad-aabf-0145-57a3-28c38338f970@ilbers.de \
    --to=asmirnov@ilbers.de \
    --cc=henning.schild@siemens.com \
    --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