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

Re: Maintaining kernel source in sarge

On Sun, 21 Sep 2003 20:12:26 -0400, Matt Zimmerman <mdz@debian.org> said: 

> On Sun, Sep 21, 2003 at 06:36:25PM -0500, Manoj Srivastava wrote:
>> On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman <mdz@debian.org>
>> said:
>> > 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
>> dependency/ordering facility?

> As far as I know, there is no external interface (the dependency
> information is stored in shell variables inside the script).

> The scripts handle ordering by testing each dependency, and if it is
> not already applied, invoking the corresponding apply script.  In
> this way, all dependencies should be applied in proper order.
> Rollback could presumably be implemented by unapplying all patches
> if any patch fails (dh-kpatches should now implement correct
> ordering for unapplication as well).

	Well, if I have asked for 5 patches to be applied (preempt,
 lowlatency, skas, device-mapper, lsm2, and debianlogo, in a recent
 invocation), the lsm2 script indeed failed -- but only after preempt,
 lowlatency, skas,  and device-mapper patches were applied (I did not
 have acl kernel-patch on the machine). It would have been nice to
 know about that before all the patches were applied. 

> It may indeed make sense to move some of this logic into
> kernel-package, if you are willing to do it.

	I am always willing to improve my packages; the constraints
 are ability (I would need to grok the details of the current
 implementation), time, and collaboration (I would need to find out
 how to get a hook into the current patch dependency setup).

	I would also like to incorporate conflict mechanisms -- so
 patch developers can give a hint about patches that are not
 compatible (the swsusp patches are incompatible with most other
 patches I wanted to apply).

	Where do I start?

No proper program contains an indication which as an operator-applied
occurrence identifies an operator-defining occurrence which as an
indication-applied occurrence identifies an indication-defining
occurrence different from the one identified by the given indication
as an indication-applied occurrence. ALGOL 68 Report
Manoj Srivastava   <srivasta@debian.org>  <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

Reply to: