diff mbox

[3/3] builddeb: add make fastdeb-pkg target

Message ID 20170331130941.5250-4-riku.voipio@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Riku Voipio March 31, 2017, 1:09 p.m. UTC
From: Riku Voipio <riku.voipio@linaro.org>

Currently, the deb-pkg and bindeb-pkg targets create multiple packages
for the kernel binaries, headers, userspace headers and firmware.

For developers who generate Debian packages as part of their development
workflows, it's often not necessary to generate all these packages.

Introduce new target, fastdeb-pkg, which only generates kernel packages.
Re-order package build order so that kernel binary package is created
first and we can exit cleanly unless generating rest packages with the
old bindeb-pkg and deb-pkg targets.

Cc: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Tested-By: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
---
 scripts/package/Makefile |  7 ++++++-
 scripts/package/builddeb | 49 +++++++++++++++++++++++++-----------------------
 2 files changed, 32 insertions(+), 24 deletions(-)

Comments

Masahiro Yamada April 18, 2017, 2:31 p.m. UTC | #1
Hi.


2017-03-31 22:09 GMT+09:00  <riku.voipio@linaro.org>:
> From: Riku Voipio <riku.voipio@linaro.org>
>
> Currently, the deb-pkg and bindeb-pkg targets create multiple packages
> for the kernel binaries, headers, userspace headers and firmware.
>
> For developers who generate Debian packages as part of their development
> workflows, it's often not necessary to generate all these packages.
>
> Introduce new target, fastdeb-pkg, which only generates kernel packages.
> Re-order package build order so that kernel binary package is created
> first and we can exit cleanly unless generating rest packages with the
> old bindeb-pkg and deb-pkg targets.
>
> Cc: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Tested-By: Jim Davis <jim.epost@gmail.com>
> Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
> ---


Before expanding this even more,
please help me understand this script.

Commit 3716001b implemented source package build
at the end of the builddeb script.
However, the binary packages are still built in its own way.
(So, debian/rules is not used in general workflows,
so we need to test it explicitly somehow.)

Why do not we create a source package first,
then build binary packages from it?


rpm-pkg does that way.
(generate a spec-file, then run rpmbuild)
Riku Voipio April 20, 2017, 10:53 a.m. UTC | #2
Hi,

Thanks for taking time to review.

On 18 April 2017 at 17:31, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Before expanding this even more,
> please help me understand this script.
>
> Commit 3716001b implemented source package build
> at the end of the builddeb script.
> However, the binary packages are still built in its own way.
> (So, debian/rules is not used in general workflows,
> so we need to test it explicitly somehow.)

Historic reasons.. since the builddeb already existed, the easiest way
to implement debian/rules was to make a skeleton debian/rules that
calls builddeb indrectly.

> Why do not we create a source package first,
> then build binary packages from it?

I wouldn't do a source package per se, but we could create a debian/
directory tree and the call dpkg-buildpackage. This would be a more
substantial overhaul that might break some expected behavior of
deb-pkg targets. If people think its worth, I can give it a shot.

> rpm-pkg does that way.
> (generate a spec-file, then run rpmbuild)

speaking of the mkspec script, it would be nice to refactor it to here
documents over endless lines of echo.

Riku
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Masahiro Yamada April 21, 2017, 9:57 a.m. UTC | #3
Hi Riku,


2017-04-20 19:53 GMT+09:00 Riku Voipio <riku.voipio@linaro.org>:
> Hi,
>
> Thanks for taking time to review.
>
> On 18 April 2017 at 17:31, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Before expanding this even more,
>> please help me understand this script.
>>
>> Commit 3716001b implemented source package build
>> at the end of the builddeb script.
>> However, the binary packages are still built in its own way.
>> (So, debian/rules is not used in general workflows,
>> so we need to test it explicitly somehow.)
>
> Historic reasons.. since the builddeb already existed, the easiest way
> to implement debian/rules was to make a skeleton debian/rules that
> calls builddeb indrectly.
>
>> Why do not we create a source package first,
>> then build binary packages from it?
>
> I wouldn't do a source package per se, but we could create a debian/
> directory tree and the call dpkg-buildpackage. This would be a more
> substantial overhaul that might break some expected behavior of
> deb-pkg targets. If people think its worth, I can give it a shot.


In hindsight, it seems more straightforward to me
to build the binary packages from the source package.
But, I know this refactoring will need lots of changes, which may
break something.

Once we support this fastdeb-pkg target,
we will not be able to convert the script in that way.
(because we do not have a standard way to generate a particular binary
package from *.dsc)
That's why I asked the question, and I want to be careful.



>> rpm-pkg does that way.
>> (generate a spec-file, then run rpmbuild)
>
> speaking of the mkspec script, it would be nice to refactor it to here
> documents over endless lines of echo.

As always, cleaning patches are welcome.
Ben Hutchings April 21, 2017, 3:04 p.m. UTC | #4
On Fri, 2017-04-21 at 18:57 +0900, Masahiro Yamada wrote:
[...]
> In hindsight, it seems more straightforward to me
> to build the binary packages from the source package.
> But, I know this refactoring will need lots of changes, which may
> break something.
> 
> Once we support this fastdeb-pkg target,
> we will not be able to convert the script in that way.
> (because we do not have a standard way to generate a particular binary
> package from *.dsc)
[...]

We kind of do, though it's a relatively new feature:
https://wiki.debian.org/BuildProfileSpec

Ben.
diff mbox

Patch

diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 71b4a8af9d4d..fc86cc3ae222 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -97,6 +97,10 @@  bindeb-pkg: FORCE
 	$(MAKE) KBUILD_SRC=
 	+$(call cmd,builddeb)
 
+fastdeb-pkg: FORCE
+	$(MAKE) KBUILD_SRC=
+	+$(call cmd,builddeb)
+
 clean-dirs += $(objtree)/debian/
 
 
@@ -142,7 +146,8 @@  help: FORCE
 	@echo '  rpm-pkg             - Build both source and binary RPM kernel packages'
 	@echo '  binrpm-pkg          - Build only the binary kernel RPM package'
 	@echo '  deb-pkg             - Build both source and binary deb kernel packages'
-	@echo '  bindeb-pkg          - Build only the binary kernel deb package'
+	@echo '  bindeb-pkg          - Build all binary kernel deb packages'
+	@echo '  fastdeb-pkg         - Build only the binary kernel image deb package'
 	@echo '  tar-pkg             - Build the kernel as an uncompressed tarball'
 	@echo '  targz-pkg           - Build the kernel as a gzip compressed tarball'
 	@echo '  tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball'
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 3407826f2a99..6c2f57039d22 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -180,11 +180,6 @@  if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
 	fi
 fi
 
-if [ "$ARCH" != "um" ]; then
-	$MAKE headers_check KBUILD_SRC=
-	$MAKE headers_install KBUILD_SRC= INSTALL_HDR_PATH="$libc_headers_dir/usr"
-fi
-
 # Install the maintainer scripts
 # Note: hook scripts under /etc/kernel are also executed by official Debian
 # kernel packages, as well as kernel packages built using make-kpkg.
@@ -315,6 +310,32 @@  EOF
 
 fi
 
+# Move firmware out of kernel image package.
+if [ -e "$tmpdir/lib/firmware" ]; then
+	mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
+	rmdir "$tmpdir/lib/firmware"
+fi
+
+create_package "$packagename" "$tmpdir"
+[ "x$1" = "xfastdeb-pkg" ] && exit 0
+
+if [ -e "$fwdir/lib/firmware/$version" ]; then
+	cat <<EOF >> debian/control
+
+Package: $fwpackagename
+Architecture: all
+Description: Linux kernel firmware, version $version
+ This package contains firmware from the Linux kernel, version $version.
+EOF
+
+	create_package "$fwpackagename" "$fwdir"
+fi
+
+if [ "$ARCH" != "um" ]; then
+	$MAKE headers_check KBUILD_SRC=
+	$MAKE headers_install KBUILD_SRC= INSTALL_HDR_PATH="$libc_headers_dir/usr"
+fi
+
 # Build kernel header package
 (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > "$objtree/debian/hdrsrcfiles"
 (cd $srctree; find arch/*/include include scripts -type f) >> "$objtree/debian/hdrsrcfiles"
@@ -345,22 +366,6 @@  Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
  This is useful for people who need to build external modules
 EOF
 
-# Do we have firmware? Move it out of the way and build it into a package.
-if [ -e "$tmpdir/lib/firmware" ]; then
-	mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
-	rmdir "$tmpdir/lib/firmware"
-
-	cat <<EOF >> debian/control
-
-Package: $fwpackagename
-Architecture: all
-Description: Linux kernel firmware, version $version
- This package contains firmware from the Linux kernel, version $version.
-EOF
-
-	create_package "$fwpackagename" "$fwdir"
-fi
-
 cat <<EOF >> debian/control
 
 Package: $libc_headers_packagename
@@ -377,8 +382,6 @@  if [ "$ARCH" != "um" ]; then
 	create_package "$libc_headers_packagename" "$libc_headers_dir"
 fi
 
-create_package "$packagename" "$tmpdir"
-
 if [ -n "$BUILD_DEBUG" ] ; then
 	# Build debug package
 	# Different tools want the image in different locations