Re: [RFC][PATCH 0/3] Experiments with .dsc backend

[Alexander Smirnov <asmirnov@ilbers.de>]

Hi Henning,

> Today i wrote a recipe to apply a patch on openssl and something like
> that could have been useful. But in fact most of the recipe is the
> customization i need to do before build, and i think this series is
> missing such a hook-in place.
>
> So you fetch to orig.tar.gz and the debian and now you patch/modify the
> code and debian stuff in dpkg_runbuild_prepend() and prepend a new
> changelog entry.
>
> Having .dsc support would have saved one entry in SRC_URI. So just
> having done that i do not see too much value in having that, but maybe
> i missed something.

As I wrote, the goal of this series was to show, how bitbake could handle 
foreign-format scripts (in this case Debian). It's not for merge.

General goal is to have possibility to partially re-build Debian. Creating 
complete recipe for Debian package is duplication. All the information 
like: SRC_URI, PV, DEPENDS, MD5 is already available in Debian apt, so what 
is the value to duplicate it? This could be an option if you need to 
rebuild one-two packages. But if there are tens of packages to rebuild, for 
example, you want to switch from 'perl' to 'microperl'. For me this looks 
like unnecessary maintaining of excessive information. AFAIK this is the 
key problem in 'meta-debian' project.

Another aspect is Debian package build dependencies from 'debian/control' 
file. Now we have to explicitely duplicate deps between recipes in DEPENDS 
variable inside recipe. So, if I could fetch package in anonymous task, 
then I could also parse its 'debian/control', then I'm able to get list of 
deps and in theory initialize DEPENDS variable in recipe. In this case I'll 
be free from maintaining these deps chains for case with lots of packages.

Alex

>
>
> Henning
>
> Am Mon, 23 Apr 2018 16:21:43 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>
>> Hi everybody,
>>
>> as it was planned initially, one of the Isar feature is the ability to
>> rebuild original Debian packages with/without customizations. Doing
>> this manually in classical Yocto/OE style requires manual setting of
>> lots of variables and having a copy of Debian patch (*.debian.tar.xz)
>> for this package in your recipe's folder. Maintenance of this system
>> becomes very complicated.
>>
>> I performed a small research regarding bitbake capabilities and found
>> an interesting trick: during bitbake parsing stage (in anonymous
>> tasks) we could re-construct whole recipe (including tasks and
>> variable), and this snapshot will be stored in recipe's dynamic
>> context, that is used during pipeline execution.
>>
>> This series is just a PoC, lots of issues are still open, like:
>> - Patching upstream packages
>> - Automatic cross-recipe dependency detection to avoid duplications
>> in recipe and debian/control files
>> - etc...
>>
>> To test this series just run:
>>
>> $ bitbake hello
>>
>> After build, in hello workdir there will be a newly-baked identical
>> copy of upstream package :-)
>>
>> Feedbacks, ideas, proposals are welcome!
>>
>> With best regards,
>> Alex
>>
>> Alexander Smirnov (3):
>> buildchroot: Include texinfo to base system
>> classes/dsc: Basic Debian .dsc backend implementation
>> recipes-debian: Add example recipe to test Debian .dsc support
>>
>> meta-isar/recipes-debian/hello/hello.bb          |  10 ++
>> meta/classes/debian-dsc.bbclass                  | 112
>> +++++++++++++++++++++++
>> meta/recipes-devtools/buildchroot/buildchroot.bb |   3 +- 3 files
>> changed, 124 insertions(+), 1 deletion(-) create mode 100644
>> meta-isar/recipes-debian/hello/hello.bb create mode 100644
>> meta/classes/debian-dsc.bbclass