Quack,
On 2019-05-14 11:24, Sean Whitton wrote:
Switching the entire Haskell ecosystem over to use dh would be a
massive
amount 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