There is still a potential purpose for dh-kpatches. Maintainance of patches that are likely to remain outside the kernel (linux-patch-debianlogo) may remain easier with dh-kpatches. Additionally dh-kpatches may also fulfill the role of keeping kernel patch-handling UIs together, rather than having them drift apart; a change though is needed since instead of needing to be consistent for make-kpkg --added_patches, it needs to be handy for humans on a command-line.
Right now I'm wondering whether try to take advantage of dh-kpatches for handling some special purpose patches, versus rolling my own for the situations *I* expect to handle. Notable weaknesses of dh-kpatches for my purposes, I need tarball handling and handling of hundreds of patches and a few patch dependancies. Why do bugs #355502 and #359063 remain unresolved 8 years after reportting when they seem near-trivial to solve? -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
