[RFC Kernel PATCH 0/1] support creation of linux-perf packages

[RFC Kernel PATCH 0/1] support creation of linux-perf packages

[Cedric Hombourger]

Hello all,

As you may know we are using the kernel "make deb-pkg" infrastructure to build and
package our custom kernels. When we upgrade the kernel to a more recent version than
Debian (e.g. when targeting use of 5.x kernel while Debian 10 is on 4.19), we lose
support for perf since the created rootfs will not have a perf binary matching the
kernel version we are running (/usr/bin/perf will be looking for perf_5.3 if you are
running a 5.3 kernel). This patch modifies the builddeb and mkdebian scripts from the
Linux kernel tree to generate linux-perf packages with a structure matching Debian's

I would anticipate that our build-kernel.sh script would be modified to build/package
the kernel with "make deb-pkg KDEB_PERF=1" (should cause no harm for older kernel
builds).

I would appreciate your review comments before submitting this to the Linux kernel
folks

TIA!

Cedric Hombourger (1):
  builddeb: support creation of linux-perf packages

 scripts/package/builddeb | 32 ++++++++++++++++++++++++++++++++
 scripts/package/mkdebian | 26 ++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

-- 
2.11.0

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

[Cedric Hombourger]

Provide a mechanism for the Debian package generation scripts to also
produce perf packages in addition to the kernel packages. Pass KDEB_PERF=1
to the "make deb-pkg" command line. The structure of the packages should
match very closely with Debian's with the perf binary and support folders
suffixed with the kernel version number (Debian's /usr/bin/perf script
checks the running kernel to spawn the corresponding perf_<version>
binary). It shall also be noted that it is left to the user to specify
runtime dependencies via the added KDEB_PERF_DEPS variable. They are
indeed distro and environment specific (perf determines what features
should be compiled in after checking packages installed on the build host)

Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
---
 scripts/package/builddeb | 32 ++++++++++++++++++++++++++++++++
 scripts/package/mkdebian | 26 ++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index c4c580f547ef..76c9c49a678f 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -51,6 +51,8 @@ tmpdir="$objtree/debian/tmp"
 kernel_headers_dir="$objtree/debian/hdrtmp"
 libc_headers_dir="$objtree/debian/headertmp"
 dbg_dir="$objtree/debian/dbgtmp"
+perf_dir="$objtree/debian/linux-perf-tmp"
+perf_xy_dir="$objtree/debian/linux-perf-$VERSION.$PATCHLEVEL-tmp"
 packagename=linux-image-$version
 kernel_headers_packagename=linux-headers-$version
 libc_headers_packagename=linux-libc-dev
@@ -78,6 +80,7 @@ BUILD_DEBUG=$(if_enabled_echo CONFIG_DEBUG_INFO Yes)
 
 # Setup the directory structure
 rm -rf "$tmpdir" "$kernel_headers_dir" "$libc_headers_dir" "$dbg_dir" $objtree/debian/files
+rm -rf "$perf_dir" "$perf_xy_dir"
 mkdir -m 755 -p "$tmpdir/DEBIAN"
 mkdir -p "$tmpdir/lib" "$tmpdir/boot"
 mkdir -p "$kernel_headers_dir/lib/modules/$version/"
@@ -129,6 +132,30 @@ if is_enabled CONFIG_MODULES; then
 	fi
 fi
 
+if [ -n "$KDEB_PERF" ]; then
+	mkdir -p $perf_dir $perf_xy_dir
+	$MAKE -C tools/perf -f Makefile.perf						\
+		DESTDIR="$(readlink -f $perf_xy_dir)"					\
+		STRACE_GROUPS_DIR=share/perf_$VERSION.$PATCHLEVEL-core/strace/groups	\
+		LDFLAGS=								\
+		prefix=/usr								\
+		perf_examples_dir=share/doc/linux-perf-$VERSION.$PATCHLEVEL/examples	\
+		perf_include_dir=include/perf_$VERSION.$PATCHLEVEL			\
+		perfexecdir=lib/perf_$VERSION.$PATCHLEVEL-core				\
+		plugindir=/usr/lib/traceevent_$VERSION.$PATCHLEVEL/plugins		\
+		srctree=$(pwd)								\
+		tipdir=share/doc/linux-perf-$VERSION.$PATCHLEVEL			\
+		install
+	mv $perf_xy_dir/etc/bash_completion.d/perf					\
+		$perf_xy_dir/etc/bash_completion.d/perf_$VERSION.$PATCHLEVEL
+	mv $perf_xy_dir/usr/bin/perf $perf_xy_dir/usr/bin/perf_$VERSION.$PATCHLEVEL
+	rm -f $perf_xy_dir/usr/bin/trace
+	for p in $perf_xy_dir/usr/bin/perf-*; do
+		[ -f $p ] || continue
+		mv $p $perf_xy_dir/usr/lib/perf_$VERSION.$PATCHLEVEL-core/
+	done
+fi
+
 if [ "$ARCH" != "um" ]; then
 	$MAKE -f $srctree/Makefile headers
 	$MAKE -f $srctree/Makefile headers_install INSTALL_HDR_PATH="$libc_headers_dir/usr"
@@ -191,6 +218,11 @@ fi
 
 create_package "$packagename" "$tmpdir"
 
+if [ -n "$KDEB_PERF" ]; then
+	create_package "linux-perf-$VERSION.$PATCHLEVEL" "$perf_xy_dir"
+	forcearch="-DArchitecture=all" create_package "linux-perf" "$perf_dir"
+fi
+
 if [ -n "$BUILD_DEBUG" ] ; then
 	# Build debug package
 	# Different tools want the image in different locations
diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
index e0750b70453f..a5826b634509 100755
--- a/scripts/package/mkdebian
+++ b/scripts/package/mkdebian
@@ -207,10 +207,36 @@ Description: Linux kernel debugging symbols for $version
  all the necessary debug symbols for the kernel and its modules.
 EOF
 
+[ -n "${KDEB_PERF}" ] && cat <<EOF >> debian/control
+
+Package: linux-perf
+Section: devel
+Architecture: all
+Depends: linux-perf-${VERSION}.${PATCHLEVEL}
+Description: Performance analysis tools for Linux (meta-package)
+ This package depends on the package containing the 'perf' performance analysis
+ tools for the latest Linux kernel.
+
+Package: linux-perf-${VERSION}.${PATCHLEVEL}
+Section: devel
+Architecture: $debarch
+Depends: ${KDEB_PERF_DEPS}
+Description: Performance analysis tools for Linux $version
+ This package contains the 'perf' performance analysis tools for Linux kernel
+ version $version
+EOF
+
 cat <<EOF > debian/rules
 #!$(command -v $MAKE) -f
 
 srctree ?= .
+EOF
+
+[ -n "${KDEB_PERF}" ] && cat <<EOF >> debian/rules
+export KDEB_PERF=${KDEB_PERF}
+EOF
+
+cat <<EOF >> debian/rules
 
 build:
 	\$(MAKE) KERNELRELEASE=${version} ARCH=${ARCH} \
-- 
2.11.0

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

[Henning Schild]

Am Wed, 28 Aug 2019 09:17:33 +0200
schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:

> Provide a mechanism for the Debian package generation scripts to also
> produce perf packages in addition to the kernel packages. Pass
> KDEB_PERF=1 to the "make deb-pkg" command line. The structure of the
> packages should match very closely with Debian's with the perf binary
> and support folders suffixed with the kernel version number
> (Debian's /usr/bin/perf script checks the running kernel to spawn the
> corresponding perf_<version> binary). It shall also be noted that it
> is left to the user to specify runtime dependencies via the added
> KDEB_PERF_DEPS variable. They are indeed distro and environment
> specific (perf determines what features should be compiled in after
> checking packages installed on the build host)

Good idea, also not doing it inside Isar. I have one other debian based
non-Isar project where we have a debian/ folder for perf ;).

I would suggest trying that on ubuntu before posting.


> Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> ---
>  scripts/package/builddeb | 32 ++++++++++++++++++++++++++++++++
>  scripts/package/mkdebian | 26 ++++++++++++++++++++++++++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index c4c580f547ef..76c9c49a678f 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -51,6 +51,8 @@ tmpdir="$objtree/debian/tmp"
>  kernel_headers_dir="$objtree/debian/hdrtmp"
>  libc_headers_dir="$objtree/debian/headertmp"
>  dbg_dir="$objtree/debian/dbgtmp"
> +perf_dir="$objtree/debian/linux-perf-tmp"
> +perf_xy_dir="$objtree/debian/linux-perf-$VERSION.$PATCHLEVEL-tmp"

xy seems like a strange name, i did not even start looking why there
are two and what they are used for

>  packagename=linux-image-$version
>  kernel_headers_packagename=linux-headers-$version
>  libc_headers_packagename=linux-libc-dev
> @@ -78,6 +80,7 @@ BUILD_DEBUG=$(if_enabled_echo CONFIG_DEBUG_INFO Yes)
>  
>  # Setup the directory structure
>  rm -rf "$tmpdir" "$kernel_headers_dir" "$libc_headers_dir"
> "$dbg_dir" $objtree/debian/files
> +rm -rf "$perf_dir" "$perf_xy_dir"

Seems like this should be merged with the line before.

>  mkdir -m 755 -p "$tmpdir/DEBIAN"
>  mkdir -p "$tmpdir/lib" "$tmpdir/boot"
>  mkdir -p "$kernel_headers_dir/lib/modules/$version/"
> @@ -129,6 +132,30 @@ if is_enabled CONFIG_MODULES; then
>  	fi
>  fi
>  
> +if [ -n "$KDEB_PERF" ]; then
> +	mkdir -p $perf_dir $perf_xy_dir
> +	$MAKE -C tools/perf -f
> Makefile.perf						\
> +		DESTDIR="$(readlink -f
> $perf_xy_dir)"					\
> +
> STRACE_GROUPS_DIR=share/perf_$VERSION.$PATCHLEVEL-core/strace/groups
> \
> +
> LDFLAGS=
> \
> +
> prefix=/usr
> \
> +
> perf_examples_dir=share/doc/linux-perf-$VERSION.$PATCHLEVEL/examples
> \
> +
> perf_include_dir=include/perf_$VERSION.$PATCHLEVEL
> \
> +
> perfexecdir=lib/perf_$VERSION.$PATCHLEVEL-core
> \
> +
> plugindir=/usr/lib/traceevent_$VERSION.$PATCHLEVEL/plugins
> \
> +
> srctree=$(pwd)
> \
> +
> tipdir=share/doc/linux-perf-$VERSION.$PATCHLEVEL
> \
> +		install

These lines all seem a little long.

> +	mv
> $perf_xy_dir/etc/bash_completion.d/perf
> \
> +
> $perf_xy_dir/etc/bash_completion.d/perf_$VERSION.$PATCHLEVEL
> +	mv $perf_xy_dir/usr/bin/perf
> $perf_xy_dir/usr/bin/perf_$VERSION.$PATCHLEVEL
> +	rm -f $perf_xy_dir/usr/bin/trace
> +	for p in $perf_xy_dir/usr/bin/perf-*; do
> +		[ -f $p ] || continue
> +		mv $p
> $perf_xy_dir/usr/lib/perf_$VERSION.$PATCHLEVEL-core/
> +	done
> +fi
> +
>  if [ "$ARCH" != "um" ]; then
>  	$MAKE -f $srctree/Makefile headers
>  	$MAKE -f $srctree/Makefile headers_install
> INSTALL_HDR_PATH="$libc_headers_dir/usr" @@ -191,6 +218,11 @@ fi
>  
>  create_package "$packagename" "$tmpdir"
>  
> +if [ -n "$KDEB_PERF" ]; then
> +	create_package "linux-perf-$VERSION.$PATCHLEVEL"
> "$perf_xy_dir"
> +	forcearch="-DArchitecture=all" create_package "linux-perf"
> "$perf_dir" +fi
> +
>  if [ -n "$BUILD_DEBUG" ] ; then
>  	# Build debug package
>  	# Different tools want the image in different locations
> diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> index e0750b70453f..a5826b634509 100755
> --- a/scripts/package/mkdebian
> +++ b/scripts/package/mkdebian
> @@ -207,10 +207,36 @@ Description: Linux kernel debugging symbols for
> $version all the necessary debug symbols for the kernel and its
> modules. EOF
>  
> +[ -n "${KDEB_PERF}" ] && cat <<EOF >> debian/control
> +
> +Package: linux-perf
> +Section: devel
> +Architecture: all
> +Depends: linux-perf-${VERSION}.${PATCHLEVEL}
> +Description: Performance analysis tools for Linux (meta-package)
> + This package depends on the package containing the 'perf'
> performance analysis
> + tools for the latest Linux kernel.
> +
> +Package: linux-perf-${VERSION}.${PATCHLEVEL}
> +Section: devel
> +Architecture: $debarch
> +Depends: ${KDEB_PERF_DEPS}
> +Description: Performance analysis tools for Linux $version
> + This package contains the 'perf' performance analysis tools for
> Linux kernel

That all seems copied from Debian, except where does the "Section" come
from and why deviate?

Henning

> + version $version
> +EOF
> +
>  cat <<EOF > debian/rules
>  #!$(command -v $MAKE) -f
>  
>  srctree ?= .
> +EOF
> +
> +[ -n "${KDEB_PERF}" ] && cat <<EOF >> debian/rules
> +export KDEB_PERF=${KDEB_PERF}
> +EOF
> +
> +cat <<EOF >> debian/rules
>  
>  build:
>  	\$(MAKE) KERNELRELEASE=${version} ARCH=${ARCH} \

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

[Cedric Hombourger]

Hi Henning

On 8/30/19 3:58 PM, Henning Schild wrote:
> Am Wed, 28 Aug 2019 09:17:33 +0200
> schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:
>
>> Provide a mechanism for the Debian package generation scripts to also
>> produce perf packages in addition to the kernel packages. Pass
>> KDEB_PERF=1 to the "make deb-pkg" command line. The structure of the
>> packages should match very closely with Debian's with the perf binary
>> and support folders suffixed with the kernel version number
>> (Debian's /usr/bin/perf script checks the running kernel to spawn the
>> corresponding perf_<version> binary). It shall also be noted that it
>> is left to the user to specify runtime dependencies via the added
>> KDEB_PERF_DEPS variable. They are indeed distro and environment
>> specific (perf determines what features should be compiled in after
>> checking packages installed on the build host)
> Good idea, also not doing it inside Isar. I have one other debian based
> non-Isar project where we have a debian/ folder for perf ;).
>
> I would suggest trying that on ubuntu before posting.
>
Unfortunately Ubuntu does not use the same package structure

/usr/bin/perf is a script provided by their linux-tools-common package

it does re-route the call to perf to the actual perf binary for your kernel

So far, while package names differ, the logic is the same. Now come some 
more annoying differences:

Ubuntu does not suffix perf with _<major>.<minor> but instead has the 
perf tools at /usr/lib/linux-tools/`uname -r`/`basename $0

This is evidently an area where Debian and Ubuntu differ (Ubuntu does 
have linux-image, linux-headers and linux-libc-dev packages just like 
Debian)

So I am not quite sure how to address this without getting ugly (and 
therefore hardly upstream'able)

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)

We would need to design our solution such as distro specifics may be 
easily implemented

Cedric

>> Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
>> ---
>>   scripts/package/builddeb | 32 ++++++++++++++++++++++++++++++++
>>   scripts/package/mkdebian | 26 ++++++++++++++++++++++++++
>>   2 files changed, 58 insertions(+)
>>
>> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
>> index c4c580f547ef..76c9c49a678f 100755
>> --- a/scripts/package/builddeb
>> +++ b/scripts/package/builddeb
>> @@ -51,6 +51,8 @@ tmpdir="$objtree/debian/tmp"
>>   kernel_headers_dir="$objtree/debian/hdrtmp"
>>   libc_headers_dir="$objtree/debian/headertmp"
>>   dbg_dir="$objtree/debian/dbgtmp"
>> +perf_dir="$objtree/debian/linux-perf-tmp"
>> +perf_xy_dir="$objtree/debian/linux-perf-$VERSION.$PATCHLEVEL-tmp"
> xy seems like a strange name, i did not even start looking why there
> are two and what they are used for
>
>>   packagename=linux-image-$version
>>   kernel_headers_packagename=linux-headers-$version
>>   libc_headers_packagename=linux-libc-dev
>> @@ -78,6 +80,7 @@ BUILD_DEBUG=$(if_enabled_echo CONFIG_DEBUG_INFO Yes)
>>   
>>   # Setup the directory structure
>>   rm -rf "$tmpdir" "$kernel_headers_dir" "$libc_headers_dir"
>> "$dbg_dir" $objtree/debian/files
>> +rm -rf "$perf_dir" "$perf_xy_dir"
> Seems like this should be merged with the line before.
>
>>   mkdir -m 755 -p "$tmpdir/DEBIAN"
>>   mkdir -p "$tmpdir/lib" "$tmpdir/boot"
>>   mkdir -p "$kernel_headers_dir/lib/modules/$version/"
>> @@ -129,6 +132,30 @@ if is_enabled CONFIG_MODULES; then
>>   	fi
>>   fi
>>   
>> +if [ -n "$KDEB_PERF" ]; then
>> +	mkdir -p $perf_dir $perf_xy_dir
>> +	$MAKE -C tools/perf -f
>> Makefile.perf						\
>> +		DESTDIR="$(readlink -f
>> $perf_xy_dir)"					\
>> +
>> STRACE_GROUPS_DIR=share/perf_$VERSION.$PATCHLEVEL-core/strace/groups
>> \
>> +
>> LDFLAGS=
>> \
>> +
>> prefix=/usr
>> \
>> +
>> perf_examples_dir=share/doc/linux-perf-$VERSION.$PATCHLEVEL/examples
>> \
>> +
>> perf_include_dir=include/perf_$VERSION.$PATCHLEVEL
>> \
>> +
>> perfexecdir=lib/perf_$VERSION.$PATCHLEVEL-core
>> \
>> +
>> plugindir=/usr/lib/traceevent_$VERSION.$PATCHLEVEL/plugins
>> \
>> +
>> srctree=$(pwd)
>> \
>> +
>> tipdir=share/doc/linux-perf-$VERSION.$PATCHLEVEL
>> \
>> +		install
> These lines all seem a little long.
>
>> +	mv
>> $perf_xy_dir/etc/bash_completion.d/perf
>> \
>> +
>> $perf_xy_dir/etc/bash_completion.d/perf_$VERSION.$PATCHLEVEL
>> +	mv $perf_xy_dir/usr/bin/perf
>> $perf_xy_dir/usr/bin/perf_$VERSION.$PATCHLEVEL
>> +	rm -f $perf_xy_dir/usr/bin/trace
>> +	for p in $perf_xy_dir/usr/bin/perf-*; do
>> +		[ -f $p ] || continue
>> +		mv $p
>> $perf_xy_dir/usr/lib/perf_$VERSION.$PATCHLEVEL-core/
>> +	done
>> +fi
>> +
>>   if [ "$ARCH" != "um" ]; then
>>   	$MAKE -f $srctree/Makefile headers
>>   	$MAKE -f $srctree/Makefile headers_install
>> INSTALL_HDR_PATH="$libc_headers_dir/usr" @@ -191,6 +218,11 @@ fi
>>   
>>   create_package "$packagename" "$tmpdir"
>>   
>> +if [ -n "$KDEB_PERF" ]; then
>> +	create_package "linux-perf-$VERSION.$PATCHLEVEL"
>> "$perf_xy_dir"
>> +	forcearch="-DArchitecture=all" create_package "linux-perf"
>> "$perf_dir" +fi
>> +
>>   if [ -n "$BUILD_DEBUG" ] ; then
>>   	# Build debug package
>>   	# Different tools want the image in different locations
>> diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
>> index e0750b70453f..a5826b634509 100755
>> --- a/scripts/package/mkdebian
>> +++ b/scripts/package/mkdebian
>> @@ -207,10 +207,36 @@ Description: Linux kernel debugging symbols for
>> $version all the necessary debug symbols for the kernel and its
>> modules. EOF
>>   
>> +[ -n "${KDEB_PERF}" ] && cat <<EOF >> debian/control
>> +
>> +Package: linux-perf
>> +Section: devel
>> +Architecture: all
>> +Depends: linux-perf-${VERSION}.${PATCHLEVEL}
>> +Description: Performance analysis tools for Linux (meta-package)
>> + This package depends on the package containing the 'perf'
>> performance analysis
>> + tools for the latest Linux kernel.
>> +
>> +Package: linux-perf-${VERSION}.${PATCHLEVEL}
>> +Section: devel
>> +Architecture: $debarch
>> +Depends: ${KDEB_PERF_DEPS}
>> +Description: Performance analysis tools for Linux $version
>> + This package contains the 'perf' performance analysis tools for
>> Linux kernel
> That all seems copied from Debian, except where does the "Section" come
> from and why deviate?
>
> Henning
>
>> + version $version
>> +EOF
>> +
>>   cat <<EOF > debian/rules
>>   #!$(command -v $MAKE) -f
>>   
>>   srctree ?= .
>> +EOF
>> +
>> +[ -n "${KDEB_PERF}" ] && cat <<EOF >> debian/rules
>> +export KDEB_PERF=${KDEB_PERF}
>> +EOF
>> +
>> +cat <<EOF >> debian/rules
>>   
>>   build:
>>   	\$(MAKE) KERNELRELEASE=${version} ARCH=${ARCH} \

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

[Baurzhan Ismagulov]

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

With kind regards,
Baurzhan.

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

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

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

[Henning Schild]

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
>