FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-28-2011, 12:30 PM
Raphael Hertzog
 
Default Lintian ERROR saying dpatch is obsolete

Hi,

On Mon, 28 Nov 2011, Alexander Wirt wrote:
> And the problem that debians dpatchs is full of evil patches that makes it
> just incompatible to other quilts on non-debian systems.

I assume you meant s/dpatchs/quilt/.

Can you back up that assertion? It's true that quilt has a lot of patches
applied but AFAIK there's only one new significant feature that is not in
the upstream git repository. We have certainly not changed anything that
would lead to a quilt tree being unusable by another quilt.

And FWIW the new feature I'm thinking about is "quilt shell" which you
should most certainly appreciate if you're a dpatch-edit-patch lover.

>From my point of view this assertion is thus wrong-headed. The number of
patches is more a sign of 1/ the Debian maintainer being too busy to do
his job properly 2/ the upstream authors who are not very active either
and haven't made a release in years with quite some changes in their git
repository.

FWIW the call for help is always open: #543541 The two persons who offered
help quickly dropped away too.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111128133009.GB4910@rivendell.home.ouaza.com">ht tp://lists.debian.org/20111128133009.GB4910@rivendell.home.ouaza.com
 
Old 11-28-2011, 02:22 PM
Jon Dowland
 
Default Lintian ERROR saying dpatch is obsolete

On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> And I still like the "never touch a running system" approach. If dpatch works
> without problems, why deprecate it?

One reason is that the surface area of Debian development tools is too large
and daunting for newcomers. When alternatives for a given tool exist which are
relevant and known outside the Debian eco system and there might be some
practical use for learning those skills in other contexts, IMHO Debian-specific
solutions should need a strong argument *for* to keep, rather than *against* to
remove.


--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111128152209.GD9337@pris">http://lists.debian.org/20111128152209.GD9337@pris
 
Old 11-28-2011, 02:39 PM
Alexander Wirt
 
Default Lintian ERROR saying dpatch is obsolete

Jon Dowland schrieb am Montag, den 28. November 2011:

> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> > And I still like the "never touch a running system" approach. If dpatch works
> > without problems, why deprecate it?
>
> One reason is that the surface area of Debian development tools is too large
> and daunting for newcomers. When alternatives for a given tool exist which are
> relevant and known outside the Debian eco system and there might be some
> practical use for learning those skills in other contexts, IMHO Debian-specific
> solutions should need a strong argument *for* to keep, rather than *against* to
> remove.
imho it is that range of development tools that make us strong. I packaged
for nearly every package system in the past and it is mainly the great eco
system of debian specific tools that make debian just a joy to package.

Alex


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111128153930.GA11953@hawking.credativ.lan">http://lists.debian.org/20111128153930.GA11953@hawking.credativ.lan
 
Old 11-28-2011, 02:52 PM
Goswin von Brederlow
 
Default Lintian ERROR saying dpatch is obsolete

Alexander Wirt <formorer@debian.org> writes:

> Jon Dowland schrieb am Montag, den 28. November 2011:
>
>> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
>> > And I still like the "never touch a running system" approach. If dpatch works
>> > without problems, why deprecate it?
>>
>> One reason is that the surface area of Debian development tools is too large
>> and daunting for newcomers. When alternatives for a given tool exist which are
>> relevant and known outside the Debian eco system and there might be some
>> practical use for learning those skills in other contexts, IMHO Debian-specific
>> solutions should need a strong argument *for* to keep, rather than *against* to
>> remove.
> imho it is that range of development tools that make us strong. I packaged
> for nearly every package system in the past and it is mainly the great eco
> system of debian specific tools that make debian just a joy to package.
>
> Alex

and then you need to fix a build failure somewhere deep down in cdbs.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mxbgi6sa.fsf@frosties.localnet">http://lists.debian.org/87mxbgi6sa.fsf@frosties.localnet
 
Old 11-28-2011, 07:10 PM
Alexander Wirt
 
Default Lintian ERROR saying dpatch is obsolete

Goswin von Brederlow schrieb am Monday, den 28. November 2011:

> Alexander Wirt <formorer@debian.org> writes:
>
> > Jon Dowland schrieb am Montag, den 28. November 2011:
> >
> >> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> >> > And I still like the "never touch a running system" approach. If dpatch works
> >> > without problems, why deprecate it?
> >>
> >> One reason is that the surface area of Debian development tools is too large
> >> and daunting for newcomers. When alternatives for a given tool exist which are
> >> relevant and known outside the Debian eco system and there might be some
> >> practical use for learning those skills in other contexts, IMHO Debian-specific
> >> solutions should need a strong argument *for* to keep, rather than *against* to
> >> remove.
> > imho it is that range of development tools that make us strong. I packaged
> > for nearly every package system in the past and it is mainly the great eco
> > system of debian specific tools that make debian just a joy to package.
> >
> > Alex
>
> and then you need to fix a build failure somewhere deep down in cdbs.
such things happen and this may also happen for debhelper, dpkg, apt, and so
on.

Alex


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111128201040.GA29031@smithers.snow-crash.org">http://lists.debian.org/20111128201040.GA29031@smithers.snow-crash.org
 
Old 11-28-2011, 07:51 PM
Stefano Zacchiroli
 
Default Lintian ERROR saying dpatch is obsolete

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 technical merits of quilt vs dpatch is a totally different matter,
but Colin & Ian argument "thou-shall-not-exec-stuff-while-patching"
alone make me score quilt way higher than dpatch, for sanity of the
archive sake.)

Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Matre de confrences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
the first rule of tautology club is the first rule of tautology club
 
Old 11-28-2011, 09:41 PM
Alexander Wirt
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111128224143.GA3317@smithers.snow-crash.org">http://lists.debian.org/20111128224143.GA3317@smithers.snow-crash.org
 
Old 11-28-2011, 11:23 PM
Michael Gilbert
 
Default Lintian ERROR saying dpatch is obsolete

On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:
> 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.

Simple answer: the maintainer(s) of that tool. If he/she/they think
it needs to go, then it should.

As an aside, the process of converting a package from dpatch to source
format 3 (quilt) is rather simple and straightforward. It can be done
in less than 10 minutes per package (although the first one will
certainly take longer given learning curve/time).

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANTw=MNBFSYEOWEaWuUqp8Kdr0Jdxk0CLn8NUDj_HZ8xzp97P Q@mail.gmail.com">http://lists.debian.org/CANTw=MNBFSYEOWEaWuUqp8Kdr0Jdxk0CLn8NUDj_HZ8xzp97P Q@mail.gmail.com
 
Old 11-28-2011, 11:32 PM
Russ Allbery
 
Default Lintian ERROR saying dpatch is obsolete

Michael Gilbert <michael.s.gilbert@gmail.com> writes:
> On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:

>> 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.

> Simple answer: the maintainer(s) of that tool. If he/she/they think it
> needs to go, then it should.

If someone else is willing to be the maintainer of the tool (as is the
case here), I think it's a bit more complicated than that. I find Zack's
argument persuasive, but I don't think the situation is as simple as
"whatever the dpatch maintainer says goes."

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871usru5sl.fsf@windlord.stanford.edu">http://lists.debian.org/871usru5sl.fsf@windlord.stanford.edu
 
Old 11-28-2011, 11:41 PM
Michael Gilbert
 
Default Lintian ERROR saying dpatch is obsolete

On Mon, Nov 28, 2011 at 7:32 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:
>
>>> 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.
>
>> Simple answer: the maintainer(s) of that tool. *If he/she/they think it
>> needs to go, then it should.
>
> If someone else is willing to be the maintainer of the tool (as is the
> case here), I think it's a bit more complicated than that.

That isn't quite the case. The existing maintainer isn't stepping
down, he's consciously deprecating the tool (and will continue to
maintain it for years until the deprecation process is complete).

Anyway, from what I've seen in the past the utmost deference is always
been given to maintainers. If one wants to second-guess maintainer
decisions, they need to appeal to the tech committee.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CANTw=MO4oFzR=T6rEfJaBSZFebKKbd_EQrytznWmN1vkquu @mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 09:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org