Re: [PATCH 0/7] "apt-get source" fetch/unpack support

[Jan Kiszka <jan.kiszka@siemens.com>]

On 17.01.19 17:38, [ext] Henning Schild wrote:
> Am Thu, 17 Jan 2019 17:04:20 +0100
> schrieb Henning Schild <henning.schild@siemens.com>:
> 
>> From: Henning Schild <henning.schild@siemens.com>
>>
>> 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