[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lintian ERROR saying dpatch is obsolete



Stefano Zacchiroli schrieb am Monday, den 28. November 2011:

> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> > Its simple and things like dpatch-edit-patch are just great. I now use dpatch
> > for round 8 years and it worked every time. I don't see any reason to move
> > away.
> > 
> > And I still like the "never touch a running system" approach. If dpatch works
> > without problems, why deprecate it?
> 
> Well, there is also the cost of diversity to take into account. I don't
> doubt that for you, right now, dpatch is better than quilt. You are used
> to it and you're happy with it. But in a project as large as Debian
> diversity has a cost.
> 
> Think about learning packaging (which is an important use case, given
> that we often lament we don't have enough people power in Debian). The
> cost of package learning is proportional to the number of tools
> involved. Multiplicating the number of tools that do the same thing adds
> up to that number, for anyone who has to deal with packages maintained
> by diverse teams with potentially different habits.
> 
> To name another use case, we have learned in the past release cycles
> that the only way to keep up with Debian releases is to have a
> significant number of people that do NMUs. Given that we need those
> people, we should also try to apply a principle of least surprise from
> one package to another. For the Squeeze release I've NMU-ed packages
> maintained in yada. Not. Fun.
> 
> The maintainer surely had the right to maintain them in yada, but that
> choice induced a cost on the release cycle of others who had to learn
> yada in the unfortunate case the maintainers stopped doing her job
> properly.
> 
> We have a tradition in Debian on standardizing on interfaces, which is
> good. But also standardizing on tools has value, because it reduces the
> cost of diversity throughout the archive. If standardizing on tools is
> considered to be too much, we should at least encourage uniformity.
> That, I believe, is what Gergely is doing, and I applaud the effort.
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. I can't remember that somebody asked about deprecating well
established and working tools.

Alex


Reply to: