From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6488313435861811200 X-Received: by 10.46.84.12 with SMTP id i12mr610310ljb.14.1511252145472; Tue, 21 Nov 2017 00:15:45 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.48.20 with SMTP id w20ls66337ljw.15.gmail; Tue, 21 Nov 2017 00:15:45 -0800 (PST) X-Google-Smtp-Source: AGs4zMYZz8a3ZMBYLK8G1xHRlkY8r9kNZ78gHpNhJd8DVSHHeg8nbrn3JI2On8QhZhCgAD/zaVfw X-Received: by 10.25.168.76 with SMTP id r73mr502409lfe.41.1511252145159; Tue, 21 Nov 2017 00:15:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511252145; cv=none; d=google.com; s=arc-20160816; b=NXGH6PEhC8OMtROcw8FeuOKMignFvq1g8+gK4Yc74H7v61aVSNAt1UE2cMDyvsaZKO tDXesz5oylswQuK7T6Qf7YyTlmu23Hi+i6MnS4QjvL6CZnqfWYnRsB1wOFAeOKQ8fekR LgpGEtQleXY4K0B6Jte3EfVGYt2eWBtaSDildNYAglDKrW8iiq5LIVSFKvTTrZFq9Gl6 778a4HZ9xVpDse/1E+cE8WvlTBgU+c3lFNBpPDJtZj3iVgXZjqYHMO4R0lPuDnca+3bT XznDq5TAONSoGfbtL1U2RNlRgcCrs2vKtdv+RQIl9CxRcArSn/SN9L/7PxV+uCFQAXQk P2EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:mail-followup-to:message-id :subject:to:from:date:arc-authentication-results; bh=XQaCxumliE+RIlF4hAxv995IxgopPj/jvjuXopS6AUM=; b=M5w8k2dM5+n+2UgXtJd5QSrTffDnssA/vtww2B4G7AHWYXBHYeYPAgPi+2YSTYIy0U p/QPEpWY3YSj9quj0ohFpK+K2mnhDsdTRsHfOvPZc3+167lvfNop+s/irkOlO0UJLiem sP8HJ/zSZvgLt9un2/W0NcNxVEmjmzqkqEnx1ICPbe2OpLAUfevYsMtDoNmoxtwsSX8H HClDhdr2MC5DTUaIBTRcGl1r27S2fTed1s776AJ/WzJhgHojQKdQrqwgUd+XwBqozaqP RYQApP9xH6vfWWx/7jKfzuabBK55sbez2KVj7Z7QqIXRXy93IDo5Jqp0P+LnXC2/EtdH VrXg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id i8si1044110lfl.3.2017.11.21.00.15.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 00:15:45 -0800 (PST) Received-SPF: pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id vAL8Fi7Q020896 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 21 Nov 2017 09:15:44 +0100 Received: from localhost ([139.25.69.251]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTPS id vAL8Fiij006084 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 21 Nov 2017 09:15:44 +0100 Date: Tue, 21 Nov 2017 09:14:24 +0100 From: Christian Storm To: isar-users@googlegroups.com Subject: Re: [PATCH] Map git objects to buildchroot Message-ID: <20171121081424.fkbr2amupexta2sc@MD1KR9XC.ww002.siemens.net> Mail-Followup-To: isar-users@googlegroups.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/20170113 (1.7.2) X-TUID: yirbr8qEr2Ay > [...] > BTW: we always have option to clone git repository to workspace by > running in ${WORKDIR}/git: > > $ git repack -a > > in do_build() task. With this, no extra mount/umount logic is needed. Yes, right, providing a (proper) git checkout in the working directory solves the problem, as a mount --bind does. For a proper checkout, you'll have to have the (entire) history/tags available, i.e., not a shallow clone. For large repositories, this may take some time which a mount --bind does not consume. On the pro side, using a (proper) checkout, there's no way to mess with the repository from within the buildroot, i.e., building from the same source twice - for whatever reason - uses the exact same revision as base: Changes made to the repository in one don't affect the other. That said, I'm fine with both solutions. So, would you go ahead and post a patch, Alex? > We could consider this behavior for source 3.0 packages only by using > some flag in recipe. Well, no. This way you're entangling Debian packaging internals to the recipe. I would opt against this. Most probably you'll want to do git operations even if you don't use source 3.0 (git) packages, e.g., getting the latest git tag or whatever. So, I'd opt for doing it for every source git package, unconditionally. Kind regards, Christian -- Dr. Christian Storm Siemens AG, Corporate Technology, CT RDA ITP SES-DE Otto-Hahn-Ring 6, 81739 M�nchen, Germany