All of lore.kernel.org
 help / color / mirror / Atom feed
From: Riku Voipio <riku.voipio@linaro.org>
To: Joe Konno <joe.konno@linux.intel.com>
Cc: linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH] scripts: package: KDEB_SOURCENAME in .deb names
Date: Tue, 21 Mar 2017 10:34:36 +0200	[thread overview]
Message-ID: <CAAqcGHkCo_1z=a4bAW9GwoisVGHhyX=-xjr4BopHHwz-4b=6gQ@mail.gmail.com> (raw)
In-Reply-To: <75cdc7$20652e@orsmga004.jf.intel.com>

On 14 March 2017 at 17:47, Joe Konno <joe.konno@linux.intel.com> wrote:
> 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

Semi-related - you probably want to use bindeb-pkg (or my proposed fastdeb-pkg)
as with deb-pkg target you will generate many huge source tarballs with
identical content.

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

It is idiomatic for Debian to have the configuration also in the version string:

$ apt-cache search ^linux-image
linux-image-4.9.0-2-686-pae-unsigned - Linux 4.9 for modern PCs
linux-image-4.9.0-2-686-unsigned - Linux 4.9 for older PCs
linux-image-4.9.0-2-amd64-unsigned - Linux 4.9 for 64-bit PCs
linux-image-4.9.0-2-rt-686-pae-unsigned - Linux 4.9 for modern PCs,
PREEMPT_RT
linux-image-4.9.0-2-rt-amd64-unsigned - Linux 4.9 for 64-bit PCs, PREEMPT_RT

It is a bit of bikeshedding matter, but your users might be expecting the above
command to tell what kernels are available and "dpkg -l linux-image*" to
tell what kernels are installed.

Also I wouldn't be surprised if various scripts (dkms?) expected the
kernel packages to
start with "linux-image-".

Riku

  reply	other threads:[~2017-03-21  8:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13 22:21 [PATCH] scripts: package: KDEB_SOURCENAME in .deb names Joe Konno
2017-03-14  8:49 ` Riku Voipio
2017-03-14 15:47   ` Joe Konno
2017-03-21  8:34     ` Riku Voipio [this message]
2017-03-21 17:01       ` Joe Konno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAqcGHkCo_1z=a4bAW9GwoisVGHhyX=-xjr4BopHHwz-4b=6gQ@mail.gmail.com' \
    --to=riku.voipio@linaro.org \
    --cc=joe.konno@linux.intel.com \
    --cc=linux-kbuild@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.