public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Christian Hesse <mail@earthworm.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Kernel .patches support
Date: Sat, 25 Jun 2005 00:31:15 +0200	[thread overview]
Message-ID: <20050624223115.GL6656@stusta.de> (raw)
In-Reply-To: <200506242303.17813.mail@earthworm.de>

On Fri, Jun 24, 2005 at 11:03:17PM +0200, Christian Hesse wrote:
> On Friday 24 June 2005 09:36, Adrian Bunk wrote:
> > On Thu, Jun 23, 2005 at 11:58:27PM +0200, Christian Hesse wrote:
> > > Hi everybody,
> > >
> > > every time I apply a patch to my kernel tree I (or my scripts) make an
> > >
> > > echo $PATCHNAME $PATCHVERSION >> .patches
> > >
> > > This patch makes the file accessible via /proc/patches.gz. I think this
> > > can be handy if you want to know what patches you (or your distributor)
> > > applied to your running kernel...
> > >...
> > > Let me know what you think.
> >
> > To be honest, I'm not a fan of it.
> >
> > If e.g. looking at a Debian kernel source that has 289 different patches
> > with names like tty-locking-fixes7 applied, you'll see that this often
> > won't give you much valuable information.
> 
> You can search Debian lists, archives, ... for "tty-locking-fixes7". After 
> that you probably know what the fix is good for.

The _only_ Google hit for "tty-locking-fixes7" isn't very helpful.

I could simply download the source package for the kernel...

> On the other hand if there is a security fix in a Debian list you can check if 
> your kernel is patched by running "zcat /proc/patches.gz | grep 
> security-fix-foo-bar".

"zless /usr/share/doc/<pkgname>/Debian.src.changelog.gz" already gives 
you the same information plus information about the contents of the 
patches including CAN references and bug numbers.

> > You'd need an uniform naming convention for patches across
> > distributions, and I don't think such things are worth the effort.
> 
> If a distribution has a naming convention for itself this patch can already be 
> useful I think. Even without it can be.

If you are building your own kernel, you have to manually check that you 
don't forget to add every patch you apply to .patches .

In a distribution, the information is already present at better places.

> Christian

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


      reply	other threads:[~2005-06-24 22:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-23 21:58 [PATCH] Kernel .patches support Christian Hesse
2005-06-23 22:38 ` Karim Yaghmour
2005-06-24  6:02 ` Ian Campbell
2005-06-24  7:36 ` Adrian Bunk
2005-06-24  8:57   ` Coywolf Qi Hunt
2005-06-24 20:48     ` Christian Hesse
2005-06-24 21:03   ` Christian Hesse
2005-06-24 22:31     ` Adrian Bunk [this message]

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=20050624223115.GL6656@stusta.de \
    --to=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@earthworm.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox