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, 11:53 PM
Russ Allbery
 
Default Lintian ERROR saying dpatch is obsolete

Michael Gilbert <michael.s.gilbert@gmail.com> writes:
> On Mon, Nov 28, 2011 at 7:32 PM, Russ Allbery wrote:

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

Yes, I know. But that doesn't *intrinsically* mean that he's correct to
do so. If, for example, Joey decided that debhelper was a bad idea and
everyone should switch to CDBS, I'm sure we'd all listen closely to the
reasoning, but I don't think his opinion would automatically win.

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

Invoking governance processes in volunteer organizations full of
opinionated people is inherently painful, and hence is the option to use
only when every other course of action is even more painful. I think a
general project discussion about the future of dpatch is more useful than
a technical committee discussion of same.

--
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: 87sjl7sq9p.fsf@windlord.stanford.edu">http://lists.debian.org/87sjl7sq9p.fsf@windlord.stanford.edu
 
Old 11-29-2011, 12:04 AM
Steve Langasek
 
Default Lintian ERROR saying dpatch is obsolete

On Sun, Nov 27, 2011 at 06:44:04PM +0100, Luk Claes wrote:
> Besides it would be great that everyone uploading has a big reminder to
> switch away from dpatch. Switching to v3 quilt should be easy.

There are several features of dpatch that can't be trivially migrated to v3
quilt.

- Custom patch commands, as already discussed. Yes, we should get rid of
them, but that doesn't make it easy to convert them.

- Conditional application of patches. Some packages have patches that are
only applied on a per-architecture or per-target-distribution basis.

- Patches that don't unapply cleanly after build can be dealt with via
'rm -rf' with a custom patch system, but must be made to unapply cleanly
with v3 (quilt).

It's still probably worthwhile to push towards v3 as a standard for source
packages, but let's not ignore that there are some real challenges along the
way.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 11-29-2011, 12:55 AM
Jonas Smedegaard
 
Default Lintian ERROR saying dpatch is obsolete

On 11-11-28 at 04:53pm, Russ Allbery wrote:
> If, for example, Joey decided that debhelper was a bad idea and
> everyone should switch to CDBS, I'm sure we'd all listen closely to
> the reasoning, but I don't think his opinion would automatically win.
>

:-D


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
 
Old 11-29-2011, 01:32 AM
Paul Wise
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, Nov 29, 2011 at 9:04 AM, Steve Langasek wrote:

> *- Custom patch commands, as already discussed. *Yes, we should get rid of
> * them, but that doesn't make it easy to convert them.
>
> *- Conditional application of patches. *Some packages have patches that are
> * only applied on a per-architecture or per-target-distribution basis.
>
> *- Patches that don't unapply cleanly after build can be dealt with via
> * 'rm -rf' with a custom patch system, but must be made to unapply cleanly
> * with v3 (quilt).

All of these can be dealt with by rewriting the patch so that it is
acceptable to upstream and applied and released by them.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKTje6EP7Z+2Z09dmyQpy6QaH-pKVQvmY2iZn39QcSaQuEPrjg@mail.gmail.com">http://lists.debian.org/CAKTje6EP7Z+2Z09dmyQpy6QaH-pKVQvmY2iZn39QcSaQuEPrjg@mail.gmail.com
 
Old 11-29-2011, 06:44 AM
Stefano Zacchiroli
 
Default Lintian ERROR saying dpatch is obsolete

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

Right, this is part of the issue. In fact, this is why in my reasoning
I've favored "encouraging uniformity" over "tool standardization". What
usually happen in these cases is that the ratio of people using the de
facto standard tool will increase while the ratio of people using
something else will decrease.

You are quite opinionated on dpatch and I'm sure you're not the only
one. But there are also many people who essentially don't care and who
will be happy to follow the tool they believe "is winning", for
uniformity sake. This, imho, is what explains the growing trend of dpkg
3.0 quilt over other patch systems that can be seen at
<http://upsilon.cc/~zack/stuff/dpkg-v3/>.

In many cases, widespread habits throughout the archive are enough to
convince everybody. But you're right that we don't have anyone who can
force *you* to change; after all you can just ignore the lintian error
or even override it. Eventually, the change will just happen. Or not.
And that is part of the reason why tool transitions in Debian might take
several years to complete.

--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... 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-29-2011, 07:56 AM
Martin Wuertele
 
Default Lintian ERROR saying dpatch is obsolete

* Paul Wise <pabs@debian.org> [2011-11-29 03:33]:

> On Tue, Nov 29, 2011 at 9:04 AM, Steve Langasek wrote:
>
> > *- Custom patch commands, as already discussed. *Yes, we should get rid of
> > * them, but that doesn't make it easy to convert them.
> >
> > *- Conditional application of patches. *Some packages have patches that are
> > * only applied on a per-architecture or per-target-distribution basis.
> >
> > *- Patches that don't unapply cleanly after build can be dealt with via
> > * 'rm -rf' with a custom patch system, but must be made to unapply cleanly
> > * with v3 (quilt).
>
> All of these can be dealt with by rewriting the patch so that it is
> acceptable to upstream and applied and released by them.

Care to explain how conditional per-target-distribution patches should
be bushed upstream? Think of patches requried for debian/sid,
debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
when it comes to build dependencies.

Thanks,
Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129085645.GV10604@anguilla.debian.or.at">http ://lists.debian.org/20111129085645.GV10604@anguilla.debian.or.at
 
Old 11-29-2011, 08:04 AM
Roger Leigh
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, Nov 29, 2011 at 09:56:45AM +0100, Martin Wuertele wrote:
> * Paul Wise <pabs@debian.org> [2011-11-29 03:33]:
>
> > On Tue, Nov 29, 2011 at 9:04 AM, Steve Langasek wrote:
> >
> > > *- Custom patch commands, as already discussed. *Yes, we should get rid of
> > > * them, but that doesn't make it easy to convert them.
> > >
> > > *- Conditional application of patches. *Some packages have patches that are
> > > * only applied on a per-architecture or per-target-distribution basis.
> > >
> > > *- Patches that don't unapply cleanly after build can be dealt with via
> > > * 'rm -rf' with a custom patch system, but must be made to unapply cleanly
> > > * with v3 (quilt).
> >
> > All of these can be dealt with by rewriting the patch so that it is
> > acceptable to upstream and applied and released by them.
>
> Care to explain how conditional per-target-distribution patches should
> be bushed upstream? Think of patches requried for debian/sid,
> debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> when it comes to build dependencies.

Those belong in a version control system, not in a single source
package, which is only targetted at a single distribution. Such
things can be done very easily on per-distribution branches, e.g.:

http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=heads

Such changes would typically only affect the Debian packaging and
not require upstreaming, but even if they did per-distribution
branches would still be the way to go.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129090431.GM17458@codelibre.net">http://lists.debian.org/20111129090431.GM17458@codelibre.net
 
Old 11-29-2011, 08:08 AM
Martin Wuertele
 
Default Lintian ERROR saying dpatch is obsolete

* Roger Leigh <rleigh@codelibre.net> [2011-11-29 10:04]:

(...)
> > > > *- Conditional application of patches. *Some packages have patches that are
> > > > * only applied on a per-architecture or per-target-distribution basis.

(...)

> > > All of these can be dealt with by rewriting the patch so that it is
> > > acceptable to upstream and applied and released by them.
> >
> > Care to explain how conditional per-target-distribution patches should
> > be bushed upstream? Think of patches requried for debian/sid,
> > debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> > when it comes to build dependencies.
>
> Those belong in a version control system, not in a single source
> package, which is only targetted at a single distribution. Such
> things can be done very easily on per-distribution branches, e.g.:
>
> http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=heads
>
> Such changes would typically only affect the Debian packaging and
> not require upstreaming, but even if they did per-distribution
> branches would still be the way to go.

So the suggested solution is to put the data into an SCM somwhere
outside the package (LP, git.d.o, $somewhereelse) instead of into the
package where anyone wanting to deal with the packages is guarantied to
find it (no downtime, no network required...).

Doesn't sound like an improvement to me.

Yours Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129090839.GW10604@anguilla.debian.or.at">http ://lists.debian.org/20111129090839.GW10604@anguilla.debian.or.at
 
Old 11-29-2011, 08:10 AM
Paul Wise
 
Default Lintian ERROR saying dpatch is obsolete

On Tue, Nov 29, 2011 at 4:56 PM, Martin Wuertele wrote:

> Care to explain how conditional per-target-distribution patches should
> be bushed upstream? Think of patches requried for debian/sid,
> debian/squeeze-backports, ubuntu/Oneric Ocelot and ubuntu/Lucid Lynx
> when it comes to build dependencies.

Sounds like you are talking about patches to files in the debian/ dir,
which I would assume would not be patched by dpatch. Are you really
patching debian/ with dpatch? If so switching to dpkg-source 1.0 plus
quilt should work. For dpkg-source v3.0 quilt, patching debian/ cannot
be done by default.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKTje6HMyRkWZXCqK_6fJ8Oy+k9ztW1gH9L=XzFPrB66mHBFB w@mail.gmail.com">http://lists.debian.org/CAKTje6HMyRkWZXCqK_6fJ8Oy+k9ztW1gH9L=XzFPrB66mHBFB w@mail.gmail.com
 
Old 11-29-2011, 08:36 AM
Gergely Nagy
 
Default Lintian ERROR saying dpatch is obsolete

Alexander Wirt <formorer@debian.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.

http://lists.debian.org/debian-devel-announce/2006/03/msg00019.html

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.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vmzp8xh.fsf@algernon.balabit">http://lists.debian.org/878vmzp8xh.fsf@algernon.balabit
 

Thread Tools




All times are GMT. The time now is 06:21 AM.

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