Re: Maintaining kernel source in sarge
On Tue, 27 May 2003 11:04:07 +0200, Arnd Bergmann <firstname.lastname@example.org> said:
> The order in which the patches are applied should in general not be
> significant. If it is, it should be stated in the patch
> description. I assumed that the 'Depends' tag is semantically more a
> 'Pre-Depends', right?
> In my example, if the isdnbonding patch has to be applied after
> ethernetpadding, it would have to say so in its description.
> patch-2.4.21-pre7 can contain the same patch and should consequently
> be applied at the same time (e.g. after binfmtmisc, but before
>> That's only fine _if_ the replaced patches are similar enough so
>> that any patch in the debian set, that would depend on those, can
>> still apply atop the new one. That is, if there are several
>> revisions of a given fix, we'll have to use versionned Provides:
>> and Depends:, or we're doomed. Not that it's impossible, but I'm
>> not sure it's exactly trivial to implement...
> Yes, versioned patches are a problem that I did not think of. I
> assumed that one patch providing the functionality of another one is
> always a superset. It may be possible to require versioned patches
> to be made as a sequence of diffs between the versions. Of course
> that creates new problems.
I am thinking of implementing something like this in
kernel-package. Ideally, I would like to support things like:
a) Specify a range or a single kernel version that the patch applies to
b) Specify a patch version
c) specify patches (with versions) that one depends on, these
patches need be present, and shall be applied before the current
User should be able to specify a list of patches that they
want to apply; and have all the dependent patches pulled in, or warn
that patches could not be applied (not-present; failed-depends); etc.
The patches applied would be unapplied in reverse order on
I am thinking of a generic run-parts replacement with
versioned depends; so that this work be useful beyond
I wish a robot would get elected president. That way, when he came to
town, we could all take a shot at him and not feel too bad. Jack
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