Re: [PATCH] scripts: package: KDEB_SOURCENAME in .deb names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 14 Mar 2017 10:49:55 +0200
Riku Voipio <riku.voipio@xxxxxxxxxx> wrote:

> On 14 March 2017 at 00:21, Joe Konno <joe.konno@xxxxxxxxxxxxxxx>
> wrote:
> > From: Joe Konno <joe.konno@xxxxxxxxx>
> >
> > Currently, the KDEB_SOURCENAME make variable only controls the name
> > of the packaged source tarball, and does not impact the .deb
> > package names output by bindeb-pkg and deb-pkg. Presently, these
> > files are more rigidly named, as the user may only control the
> > names of .deb outputs by setting KDEB_PKGVERSION in their
> > environment.
> >
> > This patch modifies the builddeb script to use KDEB_SOURCENAME when
> > naming the image, firmware-image, headers, and libc-dev .deb output
> > files. This would allow folks who build-- for instance-- mainline,
> > stable, and next kernel packages more control over how their .deb
> > outputs are named.
> >
> > This patch also changes the default value of KDEB_SOURCENAME so as
> > not to change default .deb output file names. However, this does
> > have the side effect of renaming the source tarball generated
> > for .deb source packages.
> >
> > For example:
> >   $ KDEB_SOURCENAME="linux-mainline" make bindeb-pkg
> >
> > Would output .deb files that begin with
> >   ../linux-mainline-{image,firmware-image,headers,libc-dev}  
> 
> I'm not sure this a really useful. Next, mainline, stable etc are all
> different versions of linux, so version seems the correct place to
> describe them?

Thanks for the feedback. You make a good point.

I took this approach for the following problem as well (which I did
not mention in my initial submission, silly me):

  - Build and package the same kernel commit, but with different kernel
    configurations

If I were building and packaging different kernel commits on the same
tree, I could live without my patch. The bulleted edge case, and my
original commit message's case, do something interesting for target
installations. With some KDEB_PKGVERSION finesse, I could make multiple
versions of 'linux-configA-image' and 'linux-configB-image' available
to the target. At least for my usage, this patch can be useful.

Granted, LOCALVERSION hacking could accomplish the same thing. Maybe
it's the pedant in me, but "4.11.0-rc2$LOCALVERSION" seems ideal for
describing a named package, be it 'linux-image', 'linux-configA-image',
or '$KDEB_SOURCENAME-image'.

> 
> > Signed-off-by: Joe Konno <joe.konno@xxxxxxxxx>
> > ---
> >  scripts/package/Makefile | 2 +-
> >  scripts/package/builddeb | 8 ++++----
> >  2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/scripts/package/Makefile b/scripts/package/Makefile
> > index 71b4a8af9d4d..e4280da03991 100644
> > --- a/scripts/package/Makefile
> > +++ b/scripts/package/Makefile
> > @@ -23,7 +23,7 @@
> >
> >  # Remove hyphens since they have special meaning in RPM filenames
> >  KERNELPATH := kernel-$(subst -,_,$(KERNELRELEASE))
> > -KDEB_SOURCENAME ?= linux-$(KERNELRELEASE)
> > +KDEB_SOURCENAME ?= linux
> >  export KDEB_SOURCENAME
> >  # Include only those top-level files that are needed by make, plus
> > the GPL copy TAR_CONTENT := $(KBUILD_ALLDIRS) .config .scmversion
> > Makefile \ diff --git a/scripts/package/builddeb
> > b/scripts/package/builddeb index 3c575cd07888..50caa143fb13 100755
> > --- a/scripts/package/builddeb
> > +++ b/scripts/package/builddeb
> > @@ -96,10 +96,10 @@ fwdir="$objtree/debian/fwtmp"
> >  kernel_headers_dir="$objtree/debian/hdrtmp"
> >  libc_headers_dir="$objtree/debian/headertmp"
> >  dbg_dir="$objtree/debian/dbgtmp"
> > -packagename=linux-image-$version
> > -fwpackagename=linux-firmware-image-$version
> > -kernel_headers_packagename=linux-headers-$version
> > -libc_headers_packagename=linux-libc-dev
> > +packagename=${sourcename}-image-$version
> > +fwpackagename=${sourcename}-firmware-image-$version
> > +kernel_headers_packagename=${sourcename}-headers-$version
> > +libc_headers_packagename=${sourcename}-libc-dev  
> 
> The style here is to use variables without curly braces unless really
> needed.

I noted the prevailing style initially, but I took the (overly)
cautious route for submission. Thanks for the note-- no more curly
braces when expanding shell variables.

> 
> >  dbg_packagename=$packagename-dbg
> >  debarch=
> >  forcearch=
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Attachment: pgpwFECH52mfL.pgp
Description: OpenPGP digital signature


[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux