Re: alternative debian/rules
Lars Wirzenius <liw@liw.fi> writes:
> On Wed, Apr 24, 2013 at 12:05:30PM -0700, Russ Allbery wrote:
>> For the record, I completely disagree with this packaging advice. Why
>> carry an upstream patch when you can handle this easily during build
>> time?
> As much as I dislike quilt, at least it makes it easy to see what change
> Debian is making, with regards to upstream. Embedding commands into
> debian/rules that modify the sources during a build is much harder to
> spot.
There are a lot of different things that can fall into the category of
"changes to upstream." debian/rules contains all the logic to pass
arguments to configure or pass special flags to the compiler, for example,
which can often have much more wide-spread changes than modifications to
files. That's also the place where we often rearrange all the
installation paths that upstream uses, or install separate configuration
files that don't come from the upstream source.
If debian/rules is using something like dh (which I realize wasn't the
case here), the changes tend to stand out. I find it easier to read a
succinct debian/rules file to see what special work the packaging is doing
relative to the dh defaults than to analyze patches.
I tend to do this sort of manipulation in debian/rules instead of in a
patch when whatever I'm doing feels like enabling an upstream option
rather than modifying upstream source code. That's particularly the case
when I'm also upstream; for various psychological reasons, I really prefer
not to carry Debian patches when I also control the upstream source. To
me, this specific case (activating one of three possible output formats
for a man page) feels more like an option than like a source code change,
since the infrastructure is built into the upstream source already.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: