Re: [Cooker] Re: [Maintainers] A plan for automake

[Frederic Crozat]

On Wed, 25 May 2005 10:37:16 +0200, Guillaume Rousse wrote:

> Guillaume Rousse wrote:
>> Frederic Crozat wrote:
>> 
>>>>>To know which version to use is very simple : just look at Makefile.in, it
>>>>>states which version of automake was used by upstream authors. Use the
>>>>>same and everything is fine, no need to worry about anything else.
>>>>
>>>>That is a real point, as it concerns strategy. Your suggestion is indeed
>>>>the easiest and most immediate way. However, it's also what led to the
>>>>current situation: hardcoding the need for automake 1.6 because upstream
>>>>developper used it instead of at least testing with current stable
>>>>automake version, make us dependant from automake 1.6 forever. That's
>>>>why I find it discussable.
>>>
>>>
>>>And why is it a problem to use the same major version of automake as
>>>software authors,except the "but it's not the latest version" reason ? I
>>>haven't seen any rationale about that.
>> 
>> My rationales were mainly to not get stuck forever with old versions of
>> automake, the same way we prefer avoiding maintaining old gcc versions.
>> Also, I wanted to reduce the number of additional packages neeeded for
>> backporting, when hardcoded version was not available in previous
>> release, whereas unversioned use was OK.
>> 
>> I realize now your strategy is safer, as it brings more garanties the
>> package will still build in the future, at a relatively low maintainance
>> overhead. You got the point. Does anyone else agree than always
>> hardcoding exact version of autotools used is better ? Or are they
>> exceptions ? In other term, can we make it a general policy ?
>> 
>> If so, we should rather revert previous 1.8 and 1.9 automake branches
>> merge. And maybe still clean up unversioned
>> binaries/alternatives/virtual packages in our automake packages.
> So, can we agree on the following points, so as to close this issue:
> 
> 1) we need a distinct branch for each major automake version
>  -> reintroducing 1.8 and 1.9 distinct packages

Well, if 1.9 is supposed to be backward compatible with 1.8, maybe, it
isn't needed.

> 2) we should never use non-versioned automake call in our packages
>  -> we should have rpmlint errors about it -> we should remove
>  unversioned binaries from current 1.8 package -> we should remove
>  unversioned dependencies from rpm package
> 
> I'm not sure about removing the alternative system completly. They are
> people using autotools for something else as producing
> mandrake-compliant packages, and they may be interested in still having
> a way to do it in a version-neutral way.

Hmm, how about this :
-automake (no version in package name) package is always the most recent
version of automake -when automake authors release a major version which
is not backward compatible with older release, we fork old major version
into its own package. This way, we can drop the alternative and always
force automake/aclocal to point to automake-major_version.

In specfile, we can twist my heuristic a little (I'm not sure it is wise,
comments welcome):
-when calls to aclocal/automake is needed, if latest major version of
automake was used upstream, call aclocal/automake directly (it seems
automake is not breaking backward compat too much now) -when calls to
alocal/automake is needed but old version was used upstream, hardcode old
version for automake/autoconf calls.

Comments ?
-- 
Frederic Crozat
Mandriva