From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6547633542169362432 X-Received: by 10.46.25.6 with SMTP id p6mr1349956lje.11.1524499390431; Mon, 23 Apr 2018 09:03:10 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:f608:: with SMTP id x8-v6ls64541lfe.15.gmail; Mon, 23 Apr 2018 09:03:09 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoeCt+14Q1r34pxDEkiQBJxM8r3UI8y0cITtOLFhq30VdHEmj2qwxsm2oXwAbiybUr4XWuB X-Received: by 2002:a19:6a1a:: with SMTP id u26-v6mr819269lfu.26.1524499389779; Mon, 23 Apr 2018 09:03:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524499389; cv=none; d=google.com; s=arc-20160816; b=mhfDZSxlH1rzhG8fj3eRq0NX/CAhVlCRnG0i7KrvBHlZ+DCr2BkD8lfWSCK0xy36km 6UCbIMhk74Ebv5ocK9pzCyibZHg8hE4N6IAO1Kg5cwcP3G7dDc23EC1776cN8IWN9i0e eFdMJmVGyCVpQF6MjM3ZZgtFnDw129ltIrFW/daKGMCH3cZM7u6kdqGxlV5RY+k9vlnj PURksJEVirDR+KeFEWMlh55+MrDSapgDe8tVfCJFU5QyQZPAfNkTvxp8qSkXPkHeOnAX g0n60MXCl0fTvvhHRk1G/0eZJtpvhL84ObpYbvvUF4FAIuTxkAWVfglZPrAgA56sQddy AhCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=3DtketKbZUCH754BNqnm8blzRKiHtronMjjWwjIR3IQ=; b=OYwwpuYck1PEcJqXdA8D0oZXT8ph5ycBvAM1MMcTwoPpxPx8VKT1bOgfOWVmDVGGte AwKelmFe5VVzX0Y6HIBDir2LA3+WFpkYUDeepIOnplhcYJe4NKUg5EVtk9kxoEjvzmmb MsICByX6qN5fAQnxtyibniRR7fuWP3vDK0nSqMLUHXiN0Ua+K2uHmYB9EtnaHpZGfNjW X8nf3txVy2ZoiwpOsWGcZeSUUww4flhXiw7UsaNtM2sJ1Xgo7h+sVN10eE/q050C+val Mvr0P5KG0pXADPNKGVMwCga8l5mwFdwTP5Z60/NvAK1UjaP1vhuMSWtvv+u/wWgLx6+K W8lA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id b15-v6si229169lfg.2.2018.04.23.09.03.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 09:03:09 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w3NG38Fs028969 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Apr 2018 18:03:09 +0200 Received: from mmd1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w3NG38aF018571; Mon, 23 Apr 2018 18:03:08 +0200 Date: Mon, 23 Apr 2018 18:03:07 +0200 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: [RFC][PATCH 0/3] Experiments with .dsc backend Message-ID: <20180423180307.111a3f62@mmd1pvb1c.ad001.siemens.net> In-Reply-To: <52a4801e-ef31-bdc8-5a77-b2def3b90503@ilbers.de> References: <20180423132146.14743-1-asmirnov@ilbers.de> <20180423163616.6f038064@mmd1pvb1c.ad001.siemens.net> <52a4801e-ef31-bdc8-5a77-b2def3b90503@ilbers.de> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 7pPsWHVYmyIh Am Mon, 23 Apr 2018 18:26:10 +0300 schrieb Alexander Smirnov : > On 04/23/2018 05:36 PM, Henning Schild wrote: > > Am Mon, 23 Apr 2018 16:21:43 +0300 > > schrieb Alexander Smirnov : > > > >> 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 :-) > > > > Interesting idea, but my personal feeling is that Isar already uses > > a lot of bitbake magic and we should maybe try to avoid introducing > > more where feasible. > > > > Bitbake was designed for Open Embedded, so it doesn't consider our > Isar/Debian usecases. And roughly speaking, bitbake usage in Isar is > a kind of hack at all. In such questions, I'd more prefer to focus on > the features we need and extend bitbake, instead of applying Yocto > philosophy to Isar. But this also is only my personal feeling. > > >> Feedbacks, ideas, proposals are welcome! > > > > So my feedback would be that the .dsc to recipe step should be put > > in a helper tool in the scripts directory. People that want to > > modifiy upstream packages would generate an isar-recipe with the > > tool once. Modifications in the form of patches could go on top. > > Or would this limit the envisioned feature in any way? > > IMHO this is undesired behavior: > - Extra step to generate new recipes Yes, but you can see it. > - Extra step to add these recipes to build No, not really. You will have to mention your recipe somewhere if you want it in your image. What is does and how does not change that fact. BTW, did you try overloading something like an essential package? Think of something that is in buildchroot and needs to be updated in there. (libc in the worst case ...) > - Headache with maintenance: you touch some dsc -> you need to > regenerate new recipes etc... True, but major changes in the upstream package will probably make your patches not apply anymore. So i suspect headache here as well, the one thing you do with such a tool is story copies of possibly outdated dscs, which indeed is a bad idea. So the online recipe generation is probably the way to go. > - You should somehow/somewhere list of .dsc files > So this looks like a completely new ecosystem. > > .dsc is standard format to describe Debian source packages. So > anyway, to be Debian compliant Isar should support this format. > > > > > I also fear that this could complicate the reproducable build > > story. > > In general this doesn't affect reproducibility at all. The key > difference from typical recipe (build from tarball), that SRC_URI is > derived dynamically from .dsc file during parsing stage. The > remaining part of the pipeline stays untouched. It affects it because we will have to redirect every fetch to a local cache, and it introduces fetching. Henning > > > > Henning > > > >> 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 > >> > >