John Goerzen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote:
>> > > How is that not true if one knows a given patch system and does know
>> > > about your VCS and needs to work on one of your packages. Do they have
>> >
>> > They just apt-get source, hack away, and send me a diff.
>>
>> Also true for any debian patch system, but with the gain the debian specific
>
> No, it's not, because for most of them, the "source" that you get with
> apt-get source is a tar.gz file and a debian/ directory. You can NOT
> just hack away on that like you would any package. You MUST learn the
> specific tool to do ANYTHING.
As far as I know, this is only true for one specific patch system which
I distaste so much that I always forget its name. dpatch and quilt,
which are often used and recommended, use a standard unpacked source
tree with a debian directory in it.
>> But you lose debian specific patches to be clearly separated from the
>> upstrem
>> source (digging diff.gz for that is not fun), unless one knows where to find
>
> First, what is a "Debian-specific patch?" Isn't everything in diff.gz
> that?
No, of course not. In many cases there are "upstream patches", which
could mean:
- patches taken from an unreleased upstream version
- patches developed by the DD and submitted to upstream, inclusion might
be promised or only hoped for
- security patches for external code that is included in the tarball and
used, but not maintained by upstream (no guarantee that their next
point release will actually contain the security fix...)
Among the really Debian-specific patches, there might also be some that
will probably always be needed, even in major new upstream versions, and
others that are Debian-specific workarounds for a problem that is likely
to be solved differently by upstream at some point in the future.
For example, tetex-base has three debian-specific patches (one of the
second type), and seven that address upstream issues. Many of the
changelogs of other packages also indicate a similiar organization
("dropped patch-foo which is included upstream", "dropped patch-bar, no
need to change BAR_PATH any more. Add a pointer in README.Debian to the
docs for the bar option", "updated patch-baz from upstream CVS").
> I think people that are NMUing packages rarely care about this.
When NMU'ing a package, I'd really appreciate to know which changes have
which purpose and which "specificity". In particular when trying to
incorporate a fix provided by upstream - why the hell doesn't it apply
cleanly? Did the Debian maintainer already try to address the problem
differently, or is it an orthogonal change for an unrelated problem?
In the worst case, in the setup you suggest, I would have to understand
the complete diff.gz to be sure, or at least major parts of the changes
to actual source code. If there are separate, commented patches
somewhere, it's easy to tell. And even if it's not commented, one
usually can trust that changes addressing the same problem aren't
dispersed over multiple patches.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
