Re: Maintaining kernel source in sarge
Arnd wrote:
> > Let's look at your example:
> > | Patch-name: Debian base patch
> > | Patch-id: debian
> > | Architecture: all
> > | Kernel-version: 2.4.20
> > | Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ...
> > |
> > | Patch-name: Pre-patch 2.4.21-pre7
> > | Patch-id: patch-2.4.21-pre7
> > | Architecture: all
> > | Kernel-version: 2.4.20
> > | Provides: ptrace, ethernetpadding
> >
> > Here I suppose the pre-patch is supposed to be applied first, and then
> > the application of the debian patch would only trigger application of
> > those dependant patches not provided by the pre-patch.
[...]
> 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 isdnbonding).
OK, let's assume a moment that isdnbonding declares a dependency on
ethernetpadding:
Let's apply the debian patch first, since that's what you suggested
later. This patch application will trigger, among others, the
(pre-)application of isdnbonding, which itself will trigger the
(pre-)application of ethernetpadding.
Now the "Provides" logic will have to cause the application of
patch-2.4.21-pre7 instead. That seems to settle reasonably.
But now suppose that a new version of the ptrace patch is issued.
Either we just rely on the current version of the debian patch, and
the new ptrace one won't even be considered by the mechanism here
described, if you ask for the application of patch-2.4.21-pre7. Or we
have to issue a new revision of the debian patch, either depending on
a new ptrace2 patch, declaring a conflict with old ptrace (in which
case we have to handle conflicts as well), or with a versionned
depends (which has to be implemented as well) on the new version of
ptrace.
Basically, this means bring a full dpkg/apt-like dependency model into
patch application. This overall sounds to my ears a bit like
overkill...
> The debian patch set should generally come first, except for the parts
> in it that depend on patches 'provided' by some other patch. The maintainer
> of patch-2.4.21-pre7 would have to make sure it applies on top of or mixed
> with the debian patch set.
I don't know what you mean with "mixed with". It is already some work
when we have to provide, in addition to the upstream version, a
version of the patch(es) that applies to the (current) debian kernel
(some people may have noted that dh-kpatches supports declaring such
patches since recently). I hope you're not suggesting all mixes of
sub-patches of the debian patch should be supported - this idea would
have no chance to survive long :)
Regards,
--
Yann Dirson <ydirson@altern.org> | Why make M$-Bill richer & richer ?
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
Pro: <yann.dirson@fr.alcove.com> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Reply to: