Quack, On 2019-05-14 11:24, Sean Whitton wrote:
Switching the entire Haskell ecosystem over to use dh would be a massiveamount of work, as the new dh_haskell would need a lot of testing etc. So Haskell libraries and apps would probably have to be one of the exceptions.
It took months to get somethings working for Python and Ruby and in the end years to polish all the things and migrate all packages, so it's clearly going to take quite some time.
I think one of the major feature of CDBS is the way stages are grouped in make rules and you can hook onto it or even override. Coupled with patsubst it makes some kind of loops you can use to iterate over groups of packages, which is very handy when you need to build for various versions of an interpreter. So unlike DH you can really add or override parts of these loops if your package requires it. But in the end all these rules are complex to read and maintain, and if they were very useful in the past they also pushed debhelper/dh into going forward with more bold features and I don't think CDBS adds much to the table nowadays.
I would also point out that the maintenance of CDBS has been on Jonas Smedegaard's shoulders for years now and it has been difficult having almost no backup (which I'm partly responsible of). I think I was mostly able to convince him we should work on a retirement plan but I've had no time to do anything about it. Bugs like #885407 and others are still around while we are close to release, thus I still think this is the best course of action.
On the more general topic, I believe there should be room for new tools to emerge and not-being-dh should never be a RC or even important bug. Nevertheless I think this tool has grown well and a strong recommendation would be fine. I believe as a project we could agree on major goals around deprecating tools that lost traction and proper maintenance, old versions of the tools, old patch formats and so on, and encouraging contribution around it. We could also agree on some practice to avoid like direct source patching (especially when not on a VCS). But this way you're still free to use the patching system that suits you or build your own and suggest it to the community; that's how many of our tools were built.
As for using NMU I think this is a bad idea. Even if we're supposed to care after a NMU, this is no long-term maintenance and a returning busy maintainer would not really appreciate this. I believe adoption, becoming co-maintainer or creating a team would be better if you want to make drastic changes on a package and your one-off patch lingers in the BTS.
\_o< -- Marc Dequènes