Re: [RFC Kernel PATCH 1/1] builddeb: support creation of linux-perf packages

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

Am Tue, 3 Sep 2019 17:19:14 +0200
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

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