Re: Best practice for cleaning autotools-generated files?
* Peter Samuelson <peter@p12n.org> [110317 19:12]:
> 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."
It's not higher than the risk that a program might no longer work with
a newer version of some library used. And still we have no
build-dependencies that forbid all future versions and we do not rebuild
everything every time there is a new build system.
Changing something in the source can always have some ill effects.
Editing a .c or .h file can also make a program non-functional, you have
to know what you do.
> (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.)
Removing it easy, that is simply some _OBJECTS variable. Adding can be
more complex, but in easy setting it is just the same.
> 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_.
While I'am all in favour of failing early instead of hiding things, the
question is: does this make sense?
> 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.
I'd rather say rebuilding them puts additional pressure on downstream
users to make sure it still works, as they will not usually synchronize
all those packages in the same way.
> That's sort of a side benefit, but
> can be important (say, if the downstream patch-er happens to be the
> Debian Security Team).
I think security uploads are a big argument against recreating the
build system at every build.
Security patches should be minimal, changes to the build system are
usually a big no-go there and having minimal and thus easier to review
changes is much important than then suddenly having to also patch some
minor build-system incompatiblity.
Bernhard R. Link
Reply to: