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 <[EMAIL PROTECTED]> | Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro: <[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/ | Check <http://www.debian.org/>