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

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 8 May 2018 21:31:46 +0300
schrieb 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.

I know, but as i had the need to rebuild/override a debian package i
shortly wrote down some insight for later reference.

> 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.

For the partial rebuild some support might be valuable. Imagine a
recipe that mentions a .dsc an overlay directory (i.e. for patches) and
a patch against debian/. A support class behind it could now perform
the right steps.
But i guess we need a few examples to come up with a hopefully general
pattern.

> 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.

If you follow the pattern that you want to build the whole dependency
tree, you probably will end up building everything in most cases.
Another interesting question is what happens with packages that depend
on the one you modified. Say you change a library, do you rebuild all
users?
I guess changing the ABI of a lib would be a very bad idea and most
people will want to replace single packages without going up or down
the tree.

Henning

> 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  
> 
> 
>