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

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

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.

But creating our own kernel recipe is not highest prio ATM, there is bigger fish 
to fry first.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux