Re: Lintian ERROR saying dpatch is obsolete
Alexander Wirt <firstname.lastname@example.org> writes:
> The question is: who decides? I have a bunch of packages and an established
> workflow that served me well over the last years. I don't want to learn
> another *censored* system, just because someone said its the new standard or
> it is better.
Thing is, 3.0 (quilt) is an accepted source format, 3.0 (dpatch) isn't
(thankfully). It wasn't me who decided that, I didn't make 3.0 (quilt) a
"new standard". It's the people who migrate towards it who are making it
so. While dpatch and 3.0 (quilt) don't neccessarily conflict, for the
vast majority of cases, 3.0 (quilt) should be an improvement over
dpatch, and that is one of the driving forces behind the deprecation.
I don't believe in forcing people to migrate to something they feel is
inferior, though. While the lintian error might seem like a
condtradiction to that statement, keep in mind that it's made for the
majority who don't really care, and who are happy to migrate to quilt
aswell, given some prodding. The lintian error is that prodding.
For those of you, who feel strongly about dpatch: I'd like to ask for
some patience. dpatch is not going away until there are reverse
dependencies, and I'm not going to force an inferior tool on anyone.
If that means dpatch will stick around forever, so be it. I don't like
that prospect, but I'm willing to accept it. However, I'd like to
persuade dpatch users that there ARE better tools, or at least, better
tools can be made.
My plan, which still stands, is to remove dpatch in 6 years time. I'm
fairly sure we can come to an agreement within that timeframe.
But for now, I'd like to concentrate on getting the easy cases out of
the way, so I can concentrate on the harder ones, such as yours.
> I can't remember that somebody asked about deprecating well
> established and working tools.
debmake used to be a well established and working tool (I dare say, it
usually worked better than dpatch), and it was officially deprecated
with still 60 reverse dependencies.
That's a considerably smaller number than dpatchs' reverse build-deps,
but still. In its prime, I believe debmake had similar number of
reverse-deps, if not more. It's just that debhelper was far more
lucrative compared to debmake than 3.0 quilt is to dpatch.