Re: How to cope with patches sanely
Andreas Tille <firstname.lastname@example.org> writes:
> On Fri, 25 Jan 2008, Joey Hess wrote:
> > The competing vcs situation has its problems, but no matter what
> > vcs is used for a package, you can check out the source to the
> > package using apt-get source. This allows examination and
> > modification of the source to any package, without needing to know
> > the vcs.
> I agree here, but if I understood Ben Finney in
> right, others do not.
I also agree with JoeyH's point above (again, as I understand it).
It seems to me that you can only agree with the position that "you can
check out the source to the package using 'apt-get source'. This
allows examination and midification of the source to any package" if
"the source to the package" is agreed upon.
I believe JoeyH defines "the source to the package" as being the exact
source that is then built to become the binary package; *not* an
intermediate form that must be patched again before it is ready to
build. It is that former position that I agree with, and that 'dpatch'
et al are obstacles to.
> So your main issue is that patches belong into the code not into a
> separate directory (in whatever form).
Rather (again, my understanding of JoeyH's position) that the source
package (i.e. that which is unpacked and presented by 'apt-get source
foo') can be examined in the knowledge that it is exactly the source
form that will be built, with no further patching operations required.
> I for myself would refuse to learn different vcs but if there is a
> chance for a common wrapper - I might consider changing my working
Sure. This is analogous to "I don't care what tool the package
maintainer uses to manipulate their patches, so long as I can be
completely ignorant of that tool and just 'apt-get source foo' to see
the already-patched source".
\ "I object to doing things that computers can do." —Olin |
`\ Shivers |