From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6730113598409932800 X-Received: by 2002:ac2:4359:: with SMTP id o25mr10561676lfl.147.1567586223312; Wed, 04 Sep 2019 01:37:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:43ba:: with SMTP id t26ls1738140lfl.13.gmail; Wed, 04 Sep 2019 01:37:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxfPPmOMtCbLLkaLhoSb+GGdt5ARyGnHLSDr/BmP1p6lWOgOpmPFSPCbWDE8l3nEoTBrEE6 X-Received: by 2002:a19:6455:: with SMTP id b21mr23755768lfj.167.1567586222745; Wed, 04 Sep 2019 01:37:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567586222; cv=none; d=google.com; s=arc-20160816; b=mJ5zOLhpkn0S2ptEep/9A9IThPpPS7BtnxImpBko+93dGlALsYixAI6b76fEucHZTS m3apSj6sTL3IQh/J2wVFsD+vglbKji9nObdcM1UTc6yulchFO4Rc5J40mxUgApmTABuT rpMT95X7dzOe/rfHMXVHFddRxvDfKKnWRCNfjpOxjb6R2JYyVTDPWqYHGmZrHGO2grq/ Knn48UfQZf9kc5ChDyjIoFCM8mQ2hzSptJJyDv1m97Fkdh2J/aqIapXxwQxB8KuOBYXG i2SVa/c2A6Ijs5ISkTYquUUN91Dg2VUKdJ0drPIIHPmHoZI3DtfRwNfWLw4zbYufy/eM NH3A== 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=aY06F1ew0yNmUHVk7XOtd3QfTS2WbQLaY+FwfvGCViM=; b=JCsjBrcYOYAP00pngw2qjwqUFwyDdOL2O1lFUuPS3CYzXAA5SWKxgHkQ/nXZw/p9KY VI4mFOmFnES2jfUVvBtEFv6cxAPYjuho7X2lAr+d+LjtDCzMbUNTPWDVf979IKr1k3sv F+iHcmmsM/LZHGUCsQ7ooZGOXagCmuLTshI2SvWVmP2R6Gcbb+h4syUVs7j++dT5g+Xh QdOZjA3CZXPI6wzvEw1sB4WkJA46edIXs1b3qt5QHi9hYDEsaPvD4USriWtDxQeJvlWU TQK8CxhHjLl4uPaWKS5MxZ5tSPOZBaPnO2d4n+nDgkhIjf8B8rma4cPBh4neyV74/qXm KjtQ== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id x18si197942ljm.4.2019.09.04.01.37.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 01:37:02 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x848b19u010047 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 4 Sep 2019 10:37:01 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.69.141]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x848b1wV028172; Wed, 4 Sep 2019 10:37:01 +0200 Date: Wed, 4 Sep 2019 10:37:01 +0200 From: Henning Schild To: "[ext] Jan Kiszka" Cc: Subject: Re: [RFC Kernel PATCH 1/1] builddeb: support creation of linux-perf packages Message-ID: <20190904103701.0f78b888@md1za8fc.ad001.siemens.net> In-Reply-To: References: <1566976653-174-1-git-send-email-Cedric_Hombourger@mentor.com> <1566976653-174-2-git-send-email-Cedric_Hombourger@mentor.com> <20190830155815.3042828c@md1za8fc.ad001.siemens.net> <4c350bba-d2c1-9689-b42f-9c18dcfb3e13@mentor.com> <20190903145932.GD6062@yssyq.m.ilbers.de> 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: 1r2QX7Yv0u+D Am Tue, 3 Sep 2019 17:19:14 +0200 schrieb "[ext] Jan Kiszka" : > On 03.09.19 16:59, Baurzhan Ismagulov wrote: > > Hello Cedric, > > > > On Tue, Sep 03, 2019 at 10:01:43AM +0200, Cedric Hombourger wrote: > >> Unfortunately Ubuntu does not use the same package structure > > ... > >> Anything comes to mind? > >> > >> Should we give up the idea of using builddeb and instead use our > >> own debian/{control,rules} in Isar? (Jan told me that you have > >> started to discuss/consider this) > > > > Thanks for summarizing the differences. I'm afraid there is no > > silver bullet, it will diverge. As I see it, the approach matrix is > > still the same: > > > > generic specific > > > > own complex simple > > repetitive > > > > upstream complex complex > > fragile fragile > > > > For a single downstream project, I'd choose own-specific at the > > cost of some repetition. I assume it to require less effort than > > upstream-generic. In my understanding, this is what Ubuntu does due > > to practical reasons. Unifying the three upstreams is a noble task, > > but I don't see anyone feeling inclined to solve that for the > > long-term. > > > > For Isar or a generic base layer on top of it, the effort mix will > > be different. Upstream-specific doesn't make sense, and > > upstream-generic is difficult due to the reasons in your mail. The > > alternative is copying own-specific. Given enough permutations, > > this will become unmanageable at some point (updating will be > > costly and error-prone). Start with own-generic via e.g. sed > > config -- and you end up with your own version of > > deb-pkg. So, here the question is how many variants one is going to > > ultimately have. > > > > For the generic case, I don't see approaches better than deb-pkg > > ATM. IMHO, it doesn't have to be ugly. They already support e.g. > > rpm; do they have variants for Fedora, SUSE, etc.? > > > > Addressing also Ubuntu would by a nice by-catch but not a must-have. > We need to get Debian right first. I do not care about ubuntu either, but i reviewed a kernel patch where not wearing my isar-glasses. Having support for building perf as a debian package is a nice upstream feature anyways, no matter if isar uses it. Or keeps using it in the future. > Yes, moving away from builddeb is seriously considered as the current > model makes the kernel build also "one off" /wrt all other packages. > Plus we repackage anyway because upstream is not generic enough to > allow us modeling the packages in a way that makes them drop-in > replacements for the Debian kernel. And having the control downstream > would also make it easier to account for small differences in the > various Debian flavors - if there is a user. Agreed. That repackaging and other custom stuff makes clear that upstream kernel does not fit our needs. And we can not get our patches for some aspects upstream. Henning > But creating our own kernel recipe is not highest prio ATM, there is > bigger fish to fry first. > > Jan >