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

dpatch 2.0.0 uploaded to experimental



(Umm... err... *swallow*, *crowd laughs*, well...)

Hellooooooooo Nurse! I mean, PEOPLE!

I always wanted to read my own post to debian-devel-announce, so I now
take the opportunity to pollute^Wannounce a set of BIG changes in
dpatch. There are significant changes in both the code and in how the
source is managed. Since most of you are probably not interested in
the latter, I will start explaining that.

In short: the rewrite did not happen in CVS, and CVS probably will not
be kept entirely up-to-date (meaning that only the releases will be
committed there). Instead, I used `arch'[1] for version control. See
the instructions[2] for how to obtain the sources from arch directly.

So! After this short advertisement, let me continue with the more
interesting developments!

First of all: where to get it? dpatch 2.0.0 was uploaded to
experimental today, and - just in case - is also available from
http://people.debian.org/~algernon/.

In short: dpatch has been rewritten, but from the users perspective it
should be fully backwards compatible. That is, existing users will not
find their packages broken by the rewrite. The rewrites main purpose
was to collect the logic into one place, so only that one single point
has to know how to deal with debian/patches. This - call it a library
for now - provides an unified interface to scripts, so that they do
not have to touch the patches directly at all.

Ok, ok, I stop talking in pictures and go on with the glory details.

All the logic is now in /usr/bin/dpatch. Most of the scripts have been
converted to use this. `dpatch.make' has also been rewritten, it
became a quite thin wrapper around /usr/bin/dpatch.

What does this mean for existing users who are happy with how things
were? Nothing. For them, dpatch will work exactly as it did before.

And for those, who were not satisfied? Well, quite a few things...
One of the benefits is that if you do not like the default
patch-stamp, or the way dpatch.make did its stuff, you can easily
change that now: you don't include dpatch.make, but write your own
patch target: most of the time, it will be a one line call to dpatch.

For example, if you want to have a file with the applied patches in,
say, Emacs' outline format, you can do that. Either you write your
`# DP:' comments appropriately, and use something like this:

,----
| patch:
| 	dpatch apply-all
| 	dpatch cat-all --desc-only > Debian-patches.txt
`----


Or you add support for your dpatch scripts to handle a
package-specific option, and use that. Before adding non-standard
options, please think twice, and contact us, so we can prepare some
sort of naming guideline. Anyways, all options with a `pkg-' prefix
are reserved for the user, and are guaranteed that they will never
ever be used by dpatch. If you go this route, the relevant entry in
your debian/rules might look like this:

,----
| patch:
| 	dpatch apply-all
| 	dpatch call-all --argument=pkg-info > Debian-patches.txt
`----

You could also add code to your apply command to have a side effect
like this, but that is rude and is a colossal hack. Besides, you do
that, and I'll send my tamagotchi to sit on you.

There are probably far more cases where the new dpatch can do things
the old one could not (like applying patches to a different tree than
the current one and putting stamp files somewhere else than
debian/patches), but we didn't think of yet. I can promise that the
most interesting, weird or plain oh-my-god-this-is-disgusting ideas
will appear in the examples shipped with dpatch.

Oh, I need to mention the new ability of dpatch that makes it possible
to pipe 00list through `cpp', so that one can write complex rules like
this:

,----
| #if !defined(DEB_BUILD_ARCH_i386) && !defined(DEB_BUILD_ARCH_m68k)
| somepatch
| #endif
| 
| #include DPATCH_ARCH "/00list"
`----

And so on... This also allows C-style commands which is also a plus in
my book.

Please help us testing this release, by giving it a go, and
checking if it does not break existing functionality or if there are
more features wanted[3]!

Cheers,
--
Gergely Nagy

[1] http://www.gnu.org/software/gnu-arch/
[2] tla register-archive dpatch@packages.qa.debian.org--archive \
	http://arch.debian.org/arch/dpatch/dpatch@packages.qa.debian.org--archive
    tla get dpatch@packages.qa.debian.org/dpatch--mainline--2.0 \
	dpatch-2.0
[3] How about gettextizing dpatch? :)
[4] 404. There was no such link.

Attachment: pgpfCcMPeaqIR.pgp
Description: PGP signature


Reply to: