From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6647496723618856960 X-Received: by 2002:a2e:5d0c:: with SMTP id r12-v6mr65125ljb.8.1548695874507; Mon, 28 Jan 2019 09:17:54 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:5d9d:: with SMTP id v29-v6ls2253757lje.12.gmail; Mon, 28 Jan 2019 09:17:53 -0800 (PST) X-Google-Smtp-Source: AHgI3IYUpG0q2SAoDPPCK5NFO5D+7p4kQ9K9hYlI3m5bQzILPdmbNyN4K+RGsH+JT4/zE/PGZYcw X-Received: by 2002:a2e:5d0c:: with SMTP id r12-v6mr65124ljb.8.1548695873853; Mon, 28 Jan 2019 09:17:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548695873; cv=none; d=google.com; s=arc-20160816; b=rzCw1+BMvOLa6vn+uvuJJyQUZhcOVcm64PfvlQHhonwqvAVRsS4LPh005mbTveF4P7 TW+SPUAx0bHKLCrgdrRuVp7DwOs5X6eQ+6G29BUxEJUC4mXQb0KcUo5SVpM8MYqx3y8m d24WzObw0dt3GmMcyUZgfx4HBZ8BAnZqS7dXjKMkL6kMNdnWDHeTAXBTXy7pDQiKrnxf rxWi9KTjOQgmu86/JdMRoA0fvMe7krKnM49Hfa3F7Cdp13WO+0GoB88U7iDCupC7OAuP Z4QX8JG0cpnNqjq2kpaiWiWxpC+vclibMI85m3dLbE0ZmHYNvoyRs2gnXEYSLeqq0SDx XNKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=5ZSsZukEgQfltKRUqKiWhyYrDnycuVEtlWhN8Km49jo=; b=YSja0TFa5ENtICPg5F8L9xKGcdTZGuOFQu6NxUorUn/vmdXc7sDbXOEu17VG38hI+K vANeWnINWwC/00qoyWPPJA5gE3W0dRsa8lkzrI/nEjxaGNjLqxiJ0WqX/y9Nc/+czVc6 1LbwKbnKgE3r39VIOSGExNSMHZGCIQ8b7BeoCiOS9FwjeEg+R1G0dVJkCTigFIAZr4fH nAXgYjblv+hEyKtaRw//FyqgqkpPD7DjHkwA0RUca0gPMv1YxjFg66IGq3HuNWZLr4nV Dd+YdWzbbLBed8KmKS/aPekja6M8ngSkdAxj84Gbl0+Isd8U2sa5qBdlAEV4tuZ7Jkwk T/Ew== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id n189si715107lfa.4.2019.01.28.09.17.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 09:17:53 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x0SHHq87020651 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jan 2019 18:17:53 +0100 Received: from [139.22.44.10] ([139.22.44.10]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x0SHHq3g018703; Mon, 28 Jan 2019 18:17:52 +0100 Subject: Re: [PATCH 0/7] "apt-get source" fetch/unpack support To: "[ext] Henning Schild" , isar-users Cc: Cedric Hombourger References: <20190117160427.26556-1-henning.schild@siemens.com> <20190117173813.321197fd@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <0927d562-3ebb-c822-9b57-9e499d1afba3@siemens.com> Date: Mon, 28 Jan 2019 18:17:51 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20190117173813.321197fd@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: ACzU86D3eEg5 On 17.01.19 17:38, [ext] Henning Schild wrote: > Am Thu, 17 Jan 2019 17:04:20 +0100 > schrieb Henning Schild : > >> From: Henning Schild >> >> This series includes support for fetching upstream sources with >> "apt-get source". This will make sure we fetch exactly what matches >> out distro, without rewriting debian fetch/unpack logic. >> I did consider implementing it as an "apt://" extension to the regular >> fetcher but decided against that. You have to set SRC_APT and >> effectively pass arguement to apt-get. That fetcher can only work in >> packages and depends on buildchroot and mounting, so it can not be >> part of the general fetcher. But maybe the general fetcher could >> ignore "apt://" lines and this task will ignore anything but "apt://" >> so we can still use SRC_URI instead of SRC_APT. > > Filtering all the "apt://" entries out does not really work. There is a > call to bb.fetch.get_checksum_file_list where i can not filter, at > least i did not yet figure out how. > > And it seems that the fetcher can not be extended with a new protocol > without touching the bitbake core. Otherwise an empty implementation of > "apt://" would have been the trick to let debian do it in a completely > different step. > Not sure it is worth forcing it into SRC_URI, we are in two worlds > anyways, no need to pretend otherwise. Given that upstream bitbake supports rpm fetching and even unpacking, that might be worth to explore. At least for later, no need to delay moving with this approach forward first. I wonder, though, if we cannot extend BB via some plugin or library. It seems we just need to append our own fetcher to bb.fetch2.methods... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux