On Sun, 21 Sep 2003 20:12:26 -0400, Matt Zimmerman <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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?
manoj
--
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 <[EMAIL PROTECTED]> <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
