Re: Centralized darcs
Ian Jackson <ian@davenant.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Centralized darcs"):
>> In my experience, the key difference between whether or not I want to
>> use a patch system like quilt is whether I have an upstream to which I
>> need to feed self-contained patches that may go unapplied for extended
>> periods of time. When I'm in that situation, I need to maintain that
>> separate change in a self-contained file into which I can put notes
>> about the status of merging with upstream and which I can forward-port
>> *as an independent change* to new releases of the upstream software so
>> that I can then push it to upstream again.
> I don't think I've encountered any quilted packages. When I say
> dpkg-source -x, do I get the patched or the unpatched source ? What
> happens if I do this
> dpkg-source -x /mirror/program.dsc
> cp -a program-1.2 program-1.2.unedited
> emacs program-1.2/src/program.c
> (cd program-1.2 && debian/rules build && fakeroot debian/rules binary)
> really dpkg -i program_1.2-1_i386.deb
> program --test-mode
> diff -ru program-1.2{.unedited,} >diff
> and send you (as maintainer) the diff ?
quilt doesn't automatically apply the patches when you unpack the source,
like all the patch management software, so this works if and only if your
changes don't cause any of the other patches to fail.
I agree that it would be nice to have dpkg-source just do the right thing.
The best way to get there from here, I think, would be to provide some way
for quilt to transform its patches into dpkg-v2 patches in the package,
which would then be applied automatically. This is easier to do with
quilt than with dpatch.
> Note that there are ways of dealing with the situation you describe
> above which don't break the standard model. For example, you could have
> the .diff.gz specify the _patched_ source and store the patches
> separately in debian/patches. Every diff would appear twice but this is
> not usually a big problem. Someone who didn't know about your patch
> system would just produce a working package and a reasonable diff to
> send to the BTS (if it's not just a local change), and you as maintainer
> can do the patch system integration when you include it.
That's an interesting idea. I can't see an obvious problem with it after
a few minutes of thought, other than making it a bit harder to deal with a
quilt-using package inside a revision control system, and that could be
automated.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: