-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 26 May 2003 22:20, Yann Dirson wrote:
> If you mean, whether it can handle something like "Architecture: > !ia64, !hppa", well, not yet, although it could be done. But that > would mean stopping the use of make-kpkg-level architecture support, > just like it does not use make-kpkg-level kernel-version support. Actually, I was thinking of a different concept with a 'Replaces: tag, something like: | 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 | Replaces: ptrace, ethernetpadding | Patch-name: AMD64 CVS snapshot | Patch-id: amd64-20030417 | Architecture: i386, amd64 | Kernel-version: 2.4.20 | Depends: debian, patch-2.4.21-pre7, simicsfs | Replaces: aic7xxx > Although that may not look like a big deal, that seems to show that at > some time a redesign of the interface between make-kpkg and the > patches themselves would be a good idea. Yes, in my amd64 kernel-patch package, the first thing I did was introducing an additional layer to make that interface more flexible. I'll probably change it to use dh-kpatches, but I wasn't aware of it when I made the package. Do you think that make-kpkg and dh-kpatches could/should be merged, making the dh-kpatches information evaluated by make-kpkg if available, or do we need changes beyond that? Arnd <>< -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+0oLg5t5GS2LDRf4RAk9sAJ9mXkdo1Ecktj5vjtN+0xsjY8LXTgCdExGU kwPFctma5TMf2Qv4anlB854= =uGo9 -----END PGP SIGNATURE-----