Re: Best practice for cleaning autotools-generated files?
[Bernhard R. Link]
> It usually also make sense to think twice before patching build
> systems. Especially automake is very good in allowing many things
> changed without having to patch something. (There are some cases
> where patches are necessary, but there are also enough cases where
> patching can be easily avoided).
I see it as a question of, as the FSF puts it, "the freedom to study
how the program works, and change it to make it do what you wish
(freedom 1)." A lot of us believe that's one of the main points of
Free Software in the first place. Access to source code isn't _just_
to let you build on armel if the vendor only cares about i386.
If there _is_ some risk or perception of risk, that re-auto-tooling a
package might break it, then we're not really providing the FSF's
freedom 1. We're then saying "This is free software; downstream users
can modify the .c files, you can modify the .h files, you can modify
the manpages, but you'll want to try and avoid modifying any
Makefile.am or configure.ac files, or who knows what might happen."
(Side note: even if automake lets you change things without editing
Makefile.am, there are limits. What if you refactor to add or
remove a source file? I think Freedom 1 applies to those types of
edits as much as to trivial typo fixes.)
Better to take on this risk, such as it is, by building from source
every time. It's the only way to know we _can_. And fix whatever
issues come up. Even though it's not actually spelled out in the DFSG,
I see it as a maintainer responsibility to ensure that our software
builds from source on a Debian platform, even if you patch it, assuming
your patch itself isn't buggy.
There's also the added convenience that if you always build from
source, downstream users who patch the autotools files won't have to
wonder how to rebuild them. 'sudo apt-get build-dep packagename' and
'dpkg-buildpackage' will Just Work. That's sort of a side benefit, but
can be important (say, if the downstream patch-er happens to be the
Debian Security Team).
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Reply to: