From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6547633542169362432 X-Received: by 10.28.234.154 with SMTP id g26mr711064wmi.25.1525851463380; Wed, 09 May 2018 00:37:43 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:5413:: with SMTP id i19-v6ls658079wmb.3.gmail; Wed, 09 May 2018 00:37:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrTZM9zXiWQxw8wDzvXPRatvgYsjk3MEI80ZsagEQuQ2RH//xek0kHAIF0s8vi/TVa9zEI7 X-Received: by 2002:a1c:5f83:: with SMTP id t125-v6mr696686wmb.3.1525851462900; Wed, 09 May 2018 00:37:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525851462; cv=none; d=google.com; s=arc-20160816; b=KBIDcPUa7kt1Fg23rzMmr0cZ9r7Vx6XSQ/amRpeUv53dUPNVo4g7OFUT3kji+whqDr slhsoJCZg0CyVulCAHk6PKF0KAKpXJhWTxFdKrwBz0EhN74cbOzt2KFVP557OUxb/K7Y 28vcr68tUF5ayOjd5NCmoqBuPDwkyS9x2HJ03FYtAlN+PQju5iunArihG3caYvKMhqOF XYwK9LD67p+/4nyAV8t/qYRKawiknJar+funtmC1uRRWXMId0IMDLkleRBm9sHzFdgM3 Fmonq+dIabDNoMMS8QqKTPWUawaj/g/ipKUUyA7TqwycJPln5XigN5AP6Mu9tEaecc5W yi+A== 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=1f+2dCzxWAGaKtKzXxi3FBCR6PR/7Dyo+cY6u9u+8M8=; b=h4ed8ETlUfX9mag+qRYH9XluU4ljKM0c9l6zfAcni2AysIpqQE09ZWRrBzYnrV7gV8 B1f04GN0EYgxQ/PXrwuSg7CqOemcBbGqr42uX5O5iIvTBkZlFQtTz1m87yM9olROQu7G 9h+QqNidpgwQCGPtujRo+AkKirA4uPTbmehId9s78JSRGtyMPhuAAUo+goCTBGxhhuVW 6lKiRcS6MvAsvVn0JtctYJR1TdAiEyANaPXxw3pIhL/TQ87SKo1blCewdvb775xzaEn3 ySL3W7s381LkDe3YGaUuDPyH7N/sQk+GtjxGcY5W6JHjfFsm/berLtCBDWoWkYHdoiJq 7vgw== 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 q44-v6si2174wrb.5.2018.05.09.00.37.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 00:37:42 -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 mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w497bgQs030100 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 May 2018 09:37:42 +0200 Received: from md1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w497bgFE027347; Wed, 9 May 2018 09:37:42 +0200 Date: Wed, 9 May 2018 09:37:42 +0200 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: [RFC][PATCH 0/3] Experiments with .dsc backend Message-ID: <20180509093742.5b895ac9@md1pvb1c.ad001.siemens.net> In-Reply-To: <16341060e50.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> References: <20180423132146.14743-1-asmirnov@ilbers.de> <20180508193758.2a3f63c3@md1pvb1c.ad001.siemens.net> <16341060e50.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@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: z/CKG3k78UkO Am Tue, 8 May 2018 21:31:46 +0300 schrieb Alexander Smirnov : > 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 : > > > >> 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 > > >