Re: Maintaining kernel source in sarge
- To: firstname.lastname@example.org
- Subject: Re: Maintaining kernel source in sarge
- From: Manoj Srivastava <email@example.com>
- Date: Sun, 21 Sep 2003 18:36:25 -0500
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <20030519003205.GM30897@alcor.net> (Matt Zimmerman's message of "Sun, 18 May 2003 20:32:05 -0400")
- References: <20030518145254.GL18785@finlandia.infodrom.north.de> <email@example.com> <20030519003205.GM30897@alcor.net>
On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman <firstname.lastname@example.org> said:
> On Sun, May 18, 2003 at 12:06:21PM -0500, Manoj Srivastava wrote:
>> There is also a mechanism to order the order in which
>> kernel-patches are applied -- so if, say, a m68k kernel image
>> maintainer wanted to create a patch relative to the i386 patches,
>> they could depend on that patch, and order the m68k kernel-pacth to
>> be applied later in the chain than the i386 patch.
>> This dependency-and-ordering mechanism could be extended to third
>> party modules.
>> People interested in hammering out details of this mechanism, and
>> kernel image maintainers, please contact me; perhaps it is time to
>> create policy for kernel patches.
> dh-kpatches provides a dependency/ordering facility which has worked
> well for me in my packages. It also provides
> /usr/share/doc/kernel-image-foo/applied-patches documenting the
> package and version for each patch that is applied. I think this
> would be a good starting point for such a policy, since it is
> already being applied in Debian.
Is this dependency information easily accessible to external
scripts? It is nice that the patch scripts themselves realize when a
required patch has been installed or not, but it would work much
better if the order in which these patches were applied could also be
ordered nicely (so patches are applied in dependency order), and so
that we can abort early (before anything was modified in the local
sources) in case some dependencies have not been met.
So, is there a way that kernel-package can interface with this
love, n.: When it's growing, you don't mind watering it with a few
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C