On Tue, Jul 29, 2014 at 09:31:53PM +0200, Yann Dirson wrote: > On Mon, Jul 28, 2014 at 09:11:27PM -0700, Elliott Mitchell wrote: > > 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. > > Isn't it simpler to import those patches in a git branch (if their > home is not a git tree to start with, that is) and just manage them > with "git merge" to apply them and "git reset --hard" to unapply them ? > > Or, possibly better, use git-reintegrate (which I incidentely uploaded > to unstable a couple of days ago), which can even give you > version-control of the baseline + patch sets you'll have used over time ?
Some people may prefer that approach. Using the packaged patches has the advantage of that as long as the package maintainer uploaded a good package everywhere past that is protected by the signatures on the archive. There is also the benefit of the Debian bug-tracking so hopefully everything will have been tested to work on a fair number of machines before release. > > 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? > > Mostly because I don't have any interest left in that package, and > noone stepped for maintainance in 4 years despite the RFA. In fact, I > should really orphan the package to reflect its true state... That may indeed be for the best. This would certainly prevent anyone from thinking use of dh-kpatches was a good idea in the modern era. If we're lucky this would force the maintainers of the two very actively maintained kernel patch packages (linux-patch-grsecurity2 and linux-patch-xenomai) to step forward. -- (\___(\___(\______ --=> 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
