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 ?
If the answer is `it works just fine' then obviously I don't care and
I probably won't even notice.
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.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
