Re: more build sherrif-ery (and a touch of auto*)

[Daniel Reed <n ml org>]

On 2004-11-11T12:01-0500, Havoc Pennington wrote:
) On Thu, 2004-11-11 at 23:28 +0800, James Henstridge wrote:
) > If a package works with multiple automake versions, it is best to pick
) > the newest release, since the older versions contain known bugs (based
) > on the contents of the NEWS file).
) Packages should never "symlink" to unknown future/possible-incompatible
) releases. That's like having a function that does something undefined,
) or calling parse_some_unknown_format() on a file of known format.
)
) Packages should only use names (e.g. the automake-1.x names) that have
) an interface contract.

Outside of GNOME, a package that needs a call to Automake that does not
define what version it prefers will get the newest installed (currently up
to 1.9).

Inside GNOME, a package that needs a call to Automake that does not define
what version it prefers will get the oldest installed (down to 1.4).


If GNOME's policy is that all packages should pick a version of Automake
they prefer, then gnome-autogen.sh should emit an error if the per-package
autogen.sh stub does not define such a preference. That is, if a package
truly does need 1.4, it should explicitly declare that need.

On the same note, however, any package that does just declare 1.9 as the
preference should document that the preference declaration is simply the
latest that has been tested, and that no known issues would preclude the
package from being rebased in 1.10 or future.

Someone will also need to check that the package *does* rebase cleanly in
1.10 if and when 1.10 is released. That someone will then either change the
defined preference to 1.10, on success, or change the comment to state that
1.9 is an actual upper limit, on failure.

Perhaps something like:
  # The following causes gnome-autogen.sh to use the latest version of GNU
  # Automake. At the time of the last update to this file, the latest API
  # version of GNU Automake was 1.9.
  #
  # As system environments evolve and GNU Automake and the rest of the autotools
  # expand in use, developers may discover implementation problems that were
  # previously undetected and control-language syntax and meaning that was
  # previously ill-defined. These discoveries can lead to changes in the
  # autotools' control-language strictness and behavior, and can cause build
  # control files (such as configure.ac and Makefile.am) that were considered
  # valid by previous versions of the autotools to be rejected by revised
  # versions. These new rejections and behavior changes may point out problems
  # that have always existed in this project's build control files, but simply
  # were not previously visible as problems. Please periodically check for newer
  # versions of GNU Automake and try raising this level to ensure this package
  # always compiles with the latest version of the autotools.
  REQUIRED_AUTOMAKE_VERSION=1.9

(Perhaps with the second paragraph replaced by a hyperlink that has the
explanation posted. It might also be useful to change the gnome-autogen.sh
API so that preferences can be given as a range: "This packaging requires
features present as of this API but is only known to work reliably with the
rules enforced by versions up to this second API.")


Right now, the various autogen.sh stubs I see do (or do not) define a
preference with no comments at all. For example, gnome-icon-theme/autogen.sh
declares it needs Automake 1.6 but does not give any rationale. Is this just
stale or are there actual issues going forward? The bug-buddy/autogen.sh and
eel/autogen.sh stubs do not declare any preferences. Are these oversights,
or are the packagers relying on the default being 1.4 because of specific
upgrade problems? I'll find out eventually, but any effort expended in the
past to investigate or even resolve any rebasing issues for these components
will have been redundant.

(For those curious, bug-buddy's build input files do depend on Automake 1.4,
but eel rebases to 1.9 cleanly by just adding REQUIRED_AUTOMAKE_VERSION=1.9
to its autogen.sh stub.)

-- 
Daniel Reed <n ml org>	http://people.redhat.com/djr/	http://naim.n.ml.org/
"A professor is one who talks in someone else's sleep."