Hi, 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 ? > 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... Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
