From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6735330377709125632 X-Received: by 2002:a2e:b4d5:: with SMTP id r21mr19000372ljm.149.1571072463232; Mon, 14 Oct 2019 10:01:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9d44:: with SMTP id y4ls1887467ljj.4.gmail; Mon, 14 Oct 2019 10:01:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1CDuMtHROj8p+YkTVt+c2BoNA6nWkgYtavn58BX2lOWyM9Zl6fr+qTBmrDrqbeTbT0RzQ X-Received: by 2002:a2e:63c7:: with SMTP id s68mr19754515lje.244.1571072462671; Mon, 14 Oct 2019 10:01:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571072462; cv=none; d=google.com; s=arc-20160816; b=y5o4lazExuJCWaEr6dvaFEmDchaoVwcB2dVcqx8c7jLc/ImJWn5C50kJiJismaOt44 nUUCw8so0+WOvnVoMy1dqiF7gzZsidsAgGyUDqAa823HI0j107VXpnusf2aFlPD6MO1r 9p796O6GRFWM+KBOcxuFbJGObdbr0zbp5DEi8HXtLsuWPpCrGlex3J3E0ZVqHGMOZFe0 NGUoqj1NKhJqW83j92rSFpTXz6rl9l6sBy6QfIAgGT+r6ToAAzIqHU+HxIsyOvrp+jMA 5YYc1vHt1IkomBQx9lMhuUouHF6GhaOTo0nvrMy2WmTPCWo43ziD0bmoW7rYz8DUI8AX CFhg== 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; bh=+xgCNokMIs4zsXZ/KvDc6u7cJ8xEKo9uOkXNE9r61xY=; b=b54WPaT+Apxx+e+sefg5gEabeRvBxFBPyd/2WuIjIrgBoPx93ttEnTjP2VlCnnprBh Zyyq+jZk18GX71vB7Z44bidt1ul69ZvX4Wn++plURLMf/JVLHuQdsW7XutrZjOKYJWKD 7edJrsfCGlTgMPfBSsAKSomPHpqUJnppUSDpuyanqU8zqurIZSbJyy2OTXSzJ/fDIyhL 7q71ozEFor9qbhYpDn6FMmSuq64H236Is6FFquPkbIiMTDkFUhxBRICc5VQK8YOmH1Fm uq8DgfgiySKiKf5zwdpUrGQ9peliBiQ6lOvF1hWUECC5cMlXx6dATaZJF2MhIpdvvydh 4Y8Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id d3si564836lfq.1.2019.10.14.10.01.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Oct 2019 10:01:02 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x9EH12Bl017893 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 14 Oct 2019 19:01:02 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.0.8]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x9EH100t005426; Mon, 14 Oct 2019 19:01:00 +0200 Date: Mon, 14 Oct 2019 19:01:00 +0200 From: Henning Schild To: "Dalamagkidis, Konstantinos (MO RS EN CCIT TEC AR)" Cc: "Kiszka, Jan (CT RDA IOT SES-DE)" , "isar-users@googlegroups.com" Subject: Re: [PATCH] Add support for supplying more types of debian package relationships Message-ID: <20191014190100.329e37e5@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20190911084136.19731-1-konstantinos.dalamagkidis@siemens.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: cwqkS8sVsBf9 Am Wed, 11 Sep 2019 11:32:08 +0200 schrieb "Dalamagkidis, Konstantinos (MO RS EN CCIT TEC AR)" : > > On 11.09.19 10:41, [ext] Dalamagkidis, Konstantinos wrote: > > > We need to be able to specify other package relationships, such as > > > Pre-Depends or Provides/Replaces/Conflicts. > > > > > > This change supports supplying DEBIAN_PREDEPENDS, DEBIAN_REPLACES, > > > DEBIAN_CONFLICTS and DEBIAN_PROVIDES, as well as bitbake-style > > > RDEPENDS or RDEPENDS_{PN} variables. The DEBIAN_* take priority. > > > > > > > This, as well as your DPKG_ARCH patch, is enhancing and further > > establishing debianize.bbclase as an official interface. I already > > urged Henning to do that - which includes writing documentation for > > this. Your change here should extend that (not yet existing) > > documentation as well. > > > > One of the thing to consider while designing & enhancing the recipe > > API for debianize: We should not create something that is as > > complex as writing Debian control files directly - or even more > > complex than that. > > > > BTW, what kind of application packages are you generating for > > dpkg-raw? > > We have ca 20 packages that use dpkg-raw, split more or less > equally between configuration, scripts and some pre-built > binaries. The conflicts/replaces is used in a couple of > configuration packages. We are also porting recipes from a > previous version that was using "plain yocto", so it is easier if > we can just use RDEPENDS, RPROVIDES, etc. Personally I would > prefer to use dpkg over dpkg-raw everywhere, but other colleagues > find dpkg-raw easier. My suggestion here is to keep that patch in your layer. You having that problem 20 times does not make it common, 20 independent users would ;). So you could put that magic into a dpkg-my-layer-yocto-glue class. The deps in Isar are a pain, because we are dealing with two worlds. I personally do not think that "pretending this away" is a good idea. If you actually have configure + compile tasks in your dpkg-raw you are on the wrong track and should stop pretending its yocto! Or at least make sure all that gets done in buildchroot. If you want please explain what you are doing, like Jan asked before. Henning > Rgds > Konstantinos