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 08-16-2011, 06:33 PM
Gergely Nagy
 
Default RFC: dpatch - past, present and future

Hi!

Some of you may have heard of this ancient beast called 'dpatch'[1],
some of you might have noticed that it's been recentishly orphaned[2],
and that someone (hi!) intends to pick it up[3].

The past
========

My involvement with dpatch goes back a loong long time, and I feel
somewhat responsible for it, even though it was meant to be a relatively
short-term transitional thing until the archive starts to allow multiple
patches.

Obviously, it wasn't as short term a solution, because as of this
writing there are 809[4] source packges build-depending on it still.

Nevertheless, it hasn't been touched since 2009, and only saw a couple
of bugfixes since the end of 2007. At the same time, it accumulated a
fair number of bugreports[5]. (And that list is already shorter than it
was a couple of days ago, when I started to triage dpatch bugs)

The present
===========

Even a package that's meant to be temporary deserves better, so I took
up the task, and triaged the bugs, and prepared a new version[6] that
can be tested. It fixes 18 reported bugs, out of the 31 that is still
open. The rest are marked wontfix at the moment.

Now, why on earth am I writing all this instead of just going ahead and
uploading, and enjoying the incoming BTS spam? Good question, dear
reader, and I'll promptly get to the point!

Back in the previous decade, a tool named 'dpatch-get-origtargz' was
added to the package, which was supposed to find a way to get some kind
of upstream source: either by checking a few directories, or via apt-get
source, or by trying to do something with the watch file.

At the time, this worked remarkably well, and everyone was happy. But in
this decade, the tool is broken and bleeding from many wounds. So many,
that I opted to drop it completely: there are better and more flexible
solutions to achieve a similar goal: debian/rules get-orig-source being
one of them, debian/README.source and similar being another option,
along with version control systems, and Vcs-* fields.

However, this had the consequence of "slightly" altering
dpatch-edit-patch -b's behaviour: it used to call out to
dpatch-get-origtargz to fetch sources. Now, it doesn't.

I would like to have Your opinion, whether this is acceptable, or
whether I should reintroduce said tool (except that it would attempt to
apt-get source first, followed by debian/rules get-orig-source, and fail
afterwards, instead of trying to be needlessly clever)?

There's also a couple of interesting changes in the updated package,
which I would love to have more comments on:

* dpatch comes with a DH7+ sequence now, and one can do "dh $@ --with
dpatch". I'd love to have more testing on that, and opinions about it
too.

* dpatches that don't do anything clever (ie, they're really patch -p1
files, using the standard template) will reset the timestamp of all
patched files to the same timestamp, provided the lsdiff utility from
patchutils is present.

My question here would be whether patchutils should be promoted to
Depends for this feature? Or - $deity forbid - should this behaviour
be made optional? Or is it fine as it is, if I add a note about this
behaviour to the manual page aswell (it's alreadin in debian/NEWS)?

Furthermore, there's a couple of bugs in the BTS that are marked as
wontfix, yet, I'm not completely convinced that's the right thing to
do. So if anyone feels up to it, the following issues could use a few
pairs of eyes: #400092, #400897, #342768, #397290.

The future
==========

As for the future: I still believe dpatch is a temporary solution, and
that better tools exist now. Therefore, it is my long-term plan to
slowly deprecate dpatch, and eventually make it gracefully leave the
archive.

However, seeing that this temporary solution has existed for nine years
already, the deprecation will be of similar speed, I imagine. Therefore,
I set a personal goal to remove dpatch by 2017, which would be wheezy+2
or so. 2017, because it's been about 6 years I last touched dpatch, and
that number seemed like as good as anything, as goal when I want to
touch it for the last time, and lay it down to have a well deserved
sleep.

Closing notes
=============

There's quite a lot of changes in the version I prepared[6], if you have
a dpatch using package, or simply feel like helping me, please test it,
break it, and report bugs.

Thank you!

Links
-----

1: http://packages.debian.org/sid/dpatch
2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562697#14
3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562697#23
4: grep-dctrl -F Build-Depends "$1" -s Package
/var/lib/apt/lists/*_Sources | sort -u | awk '{print $2}' | wc -l
5: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dpatch;dist=unstable
6: http://madhouse-project.org/algernon/dpatch/2.0.32-preview/

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vqt6was.fsf@luthien.mhp">http://lists.debian.org/878vqt6was.fsf@luthien.mhp
 
Old 08-16-2011, 08:33 PM
Raphael Hertzog
 
Default RFC: dpatch - past, present and future

Hi,

On Tue, 16 Aug 2011, Gergely Nagy wrote:
> As for the future: I still believe dpatch is a temporary solution, and
> that better tools exist now. Therefore, it is my long-term plan to
> slowly deprecate dpatch, and eventually make it gracefully leave the
> archive.

How do you plan to do this?

I imagine you could print out a warning during the build process
when dpatch is invoked. It would point to some documentation explaining
the recommended alternatives...

You could also update the package description to discourage people to use
it for new packages.

But if your goal is really to get rid of it, you could just as well file
wishlist bugs on all packages build-depending on it, usertag them and
increase their severity slowly. Wishlist for now, normal in the next
release cycle and important/RC in the cycle where you want to drop it?

FWIW, we managed to get rid of 2/3 of dbs build-dependencies by filing such bugs:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@debian.org;tag=drop-dbs

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110816203355.GC11431@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110816203355.GC11431@rivendell.home.ouaza.com
 
Old 08-16-2011, 08:54 PM
Gergely Nagy
 
Default RFC: dpatch - past, present and future

Raphael Hertzog <hertzog@debian.org> writes:

> Hi,
>
> On Tue, 16 Aug 2011, Gergely Nagy wrote:
>> As for the future: I still believe dpatch is a temporary solution, and
>> that better tools exist now. Therefore, it is my long-term plan to
>> slowly deprecate dpatch, and eventually make it gracefully leave the
>> archive.
>
> How do you plan to do this?
>
> I imagine you could print out a warning during the build process
> when dpatch is invoked. It would point to some documentation explaining
> the recommended alternatives...
>
> You could also update the package description to discourage people to use
> it for new packages.

I don't want to make it spew out deprecation warnings, those are too
tempting to ignore. Updating the description, filing wishlist bugs with
patches, and providing upgrade paths for the most common cases is The
Plan. Along with an entry in debian/NEWS.

Something like a dpatch2quilt thing. While I haven't verified it yet,
I'm fairly sure most dpatches out there actually use the default
template, which is trivial to convert to quilt, preserving metadata and
all.

I expect arch-specific dpatches to be the bottleneck in migrating away
from dpatch, but I haven't started going through all the build-depending
packages yet.

> FWIW, we managed to get rid of 2/3 of dbs build-dependencies by filing such bugs:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@debian.org;tag=drop-dbs

This is a good idea, thank you!

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871uwl6prt.fsf@luthien.mhp">http://lists.debian.org/871uwl6prt.fsf@luthien.mhp
 
Old 08-16-2011, 09:06 PM
Sandro Tosi
 
Default RFC: dpatch - past, present and future

On Tue, Aug 16, 2011 at 22:54, Gergely Nagy
<algernon@madhouse-project.org> wrote:
> Something like a dpatch2quilt thing. While I haven't verified it yet,
> I'm fairly sure most dpatches out there actually use the default
> template, which is trivial to convert to quilt, preserving metadata and
> all.

there's already: /usr/share/doc/quilt/examples/dpatch2quilt.sh

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPdtAj0V3xifDnMZSNzQfT5x-cp+k+SmqWbO_AieiZ8ABUxQ0Q@mail.gmail.com">http://lists.debian.org/CAPdtAj0V3xifDnMZSNzQfT5x-cp+k+SmqWbO_AieiZ8ABUxQ0Q@mail.gmail.com
 
Old 08-16-2011, 09:10 PM
Gergely Nagy
 
Default RFC: dpatch - past, present and future

Sandro Tosi <morph@debian.org> writes:

> On Tue, Aug 16, 2011 at 22:54, Gergely Nagy
> <algernon@madhouse-project.org> wrote:
>> Something like a dpatch2quilt thing. While I haven't verified it yet,
>> I'm fairly sure most dpatches out there actually use the default
>> template, which is trivial to convert to quilt, preserving metadata and
>> all.
>
> there's already: /usr/share/doc/quilt/examples/dpatch2quilt.sh

Well then, that just makes it all the easier! I'll take a look, and see
if there are any cases that script can't handle.

Thanks!

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wred5ahd.fsf@luthien.mhp">http://lists.debian.org/87wred5ahd.fsf@luthien.mhp
 
Old 08-17-2011, 01:33 PM
Stefano Zacchiroli
 
Default RFC: dpatch - past, present and future

On Tue, Aug 16, 2011 at 10:54:30PM +0200, Gergely Nagy wrote:
> I don't want to make it spew out deprecation warnings, those are too
> tempting to ignore. Updating the description, filing wishlist bugs with
> patches, and providing upgrade paths for the most common cases is The
> Plan. Along with an entry in debian/NEWS.

Sure, deprecation warning are tempting to ignore. But, in addition to
the other means you've mentioned, what harm do they do? (Purposefully
ignoring the harm of bothering whoever reads the build log, as that kind
of "harm" is pretty much the point of any deprecation warning.)

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
 
Old 08-17-2011, 02:00 PM
Gergely Nagy
 
Default RFC: dpatch - past, present and future

Stefano Zacchiroli <zack@debian.org> writes:

> On Tue, Aug 16, 2011 at 10:54:30PM +0200, Gergely Nagy wrote:
>> I don't want to make it spew out deprecation warnings, those are too
>> tempting to ignore. Updating the description, filing wishlist bugs with
>> patches, and providing upgrade paths for the most common cases is The
>> Plan. Along with an entry in debian/NEWS.
>
> Sure, deprecation warning are tempting to ignore. But, in addition to
> the other means you've mentioned, what harm do they do? (Purposefully
> ignoring the harm of bothering whoever reads the build log, as that kind
> of "harm" is pretty much the point of any deprecation warning.)

Simply put: I hate them. Documentation is there to be read, debian/NEWS
included. If one cannot be bothered to do that, to keep up with the
rushing pace of dpatch development, bugs will be filed eventually, and
they'll notice.

And since bugs - hopefully most of them with patches - will be filed
regardless, I do not see the point in adding more noise. It doesn't save
work for anyone but me (and I do not mind going an extra mile to avoid
the deprecation warnings), but creates noise for everyone who happens to
read build logs of a dpatch using package. Potentially for readers who
couldn't care less about the packaging, either (which, I believe, would
be most of the readers).

On the other hand, adding deprecation warnings properly to dpatch isn't
as easy as a few lines, unless I want it very spammy (which I don't), so
in the long run, I'd rather spend a day more on creating patches for
dpatch->quilt conversion than spend an hour adding the deprecation
warnings.

But as always, patches are welcome!

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877h6cm92m.fsf@balabit.hu">http://lists.debian.org/877h6cm92m.fsf@balabit.hu
 
Old 08-17-2011, 02:14 PM
Guillem Jover
 
Default RFC: dpatch - past, present and future

Hi!

On Tue, 2011-08-16 at 22:33:55 +0200, Raphael Hertzog wrote:
> On Tue, 16 Aug 2011, Gergely Nagy wrote:
> > As for the future: I still believe dpatch is a temporary solution, and
> > that better tools exist now. Therefore, it is my long-term plan to
> > slowly deprecate dpatch, and eventually make it gracefully leave the
> > archive.
>
> How do you plan to do this?

[...]

> But if your goal is really to get rid of it, you could just as well file
> wishlist bugs on all packages build-depending on it, usertag them and
> increase their severity slowly. Wishlist for now, normal in the next
> release cycle and important/RC in the cycle where you want to drop it?

> FWIW, we managed to get rid of 2/3 of dbs build-dependencies by filing such bugs:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@debian.org;tag=drop-dbs

Given there's at least around 800 source packages (as Gergely pointed
out, and checking for embedded dpatch in source might reveal some more
maybe). I think filing bug reports for these right now would be too
much, and I'd propose to add a lintian check first, and wait until the
numbers decrease substantially before filing them.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110817141407.GA12107@gaara.hadrons.org">http://lists.debian.org/20110817141407.GA12107@gaara.hadrons.org
 
Old 08-17-2011, 02:44 PM
Gergely Nagy
 
Default RFC: dpatch - past, present and future

Guillem Jover <guillem@debian.org> writes:

>> But if your goal is really to get rid of it, you could just as well file
>> wishlist bugs on all packages build-depending on it, usertag them and
>> increase their severity slowly. Wishlist for now, normal in the next
>> release cycle and important/RC in the cycle where you want to drop it?
>
>> FWIW, we managed to get rid of 2/3 of dbs build-dependencies by filing such bugs:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@debian.org;tag=drop-dbs
>
> Given there's at least around 800 source packages (as Gergely pointed
> out, and checking for embedded dpatch in source might reveal some more
> maybe). I think filing bug reports for these right now would be too
> much, and I'd propose to add a lintian check first, and wait until the
> numbers decrease substantially before filing them.

Since I plan to phase out dpatch by 2017, there's plenty of time to file
those ~800 wishlist bugs. I'm not worried. This gives me plenty of time
to get it done without spamming the BTS. About 3 bugs a week on average
sounds low profile enough, and it's comfortably low enough to allow me
to actually do the patches properly.

I'm not entirely sold on the lintian check idea, either, but that might
be my lack of tea today. (Update, after a cup of tea: I'll send a patch
against lintian once 2.0.32 is uploaded to unstable.)

As for embedded dpatch: that's usually something very different to what
is currently packaged as dpatch. I do not wish to care about that, and
as such, is not and will not be included in my removal plans. (However,
if someone takes up the task, so much the better! It just won't be me.)

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87y5ysksgv.fsf@balabit.hu">http://lists.debian.org/87y5ysksgv.fsf@balabit.hu
 
Old 08-17-2011, 04:33 PM
Osamu Aoki
 
Default RFC: dpatch - past, present and future

On Tue, Aug 16, 2011 at 11:10:06PM +0200, Gergely Nagy wrote:
> Sandro Tosi <morph@debian.org> writes:
> > there's already: /usr/share/doc/quilt/examples/dpatch2quilt.sh
>
> Well then, that just makes it all the easier! I'll take a look, and see
> if there are any cases that script can't handle.

You amy want to check #581186
http://bugs.debian.org/581186

This updated script is compatible with new
QUILT_PATCH_OPTS="--reject-format=unified"

Following formats are auto detected.

# * dh_quilt_patch/dh_quilt_unpatch
# * dpatch
# * cdbs (simple-patchsys.mk)
# * dbs (dbs-build.mk)

Osamu


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

Thread Tools




All times are GMT. The time now is 04:36 PM.

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