Differences between revisions 6 and 7
Revision 6 as of 2009-03-16 03:31:10
Size: 3612
Editor: anonymous
Comment: converted to 1.6 markup
Revision 7 as of 2009-08-21 19:48:29
Size: 3587
Editor: GuillemJover
Comment: Use new DebianBug wiki word to ref bugs
Deletions are marked like this. Additions are marked like this.
Line 55: Line 55:
[[http://bugs.debian.org/376047|#376047]]. DebianBug:376047.

UNDER CONSTRUCTION

Current Situation

  • automake1.4: This is the old school package, that's been completely unsupported for a number of years (since 2002). It certainly not used with any new software and any software still using it should be migrated away from it. It is also the only package that provides "automake", cause there are still 73 packages[1] by my reckoning that build depend on automake and expect that be automake 1.4.

  • automake1.7, automake1.8, automake1.9: This is the new generation of automake. While mostly compatible with each other, each new revision brings in some backwards incompatible changes. This is mostly due to automake's free form nature, and no strict API for generating makefiles.

Right now, the "automake" command is set up as an alternative, and all these automake* packages provide those alternatives, with automake1.9 having the highest priority. This situation isn't ideal because users can't just install automake and get the expected latest version.

The Plan

  • Remove the automake and automaken provides from automake1.4 and take it out of the alternatives infrastructure (alternatively leave the alternatives but still removing the provides, with automake1.4 providing the lowest alternative value). Make clear in the package description and whatnot that automake 1.4 is deprecated and should only be used in highly special circumstances.
  • Start shipping an automake package again that would track the latest upstream version of automake (or be a dummy package that depended on the latest version) and give it the highest alternative priority. This will give most users the latest version (and hence have a better automake experience), while still allowing packages to depend on other versions.
  • Leave the alternatives system in place for >= 1.7 versions of automake, to give people the ability to say "No, I want my system to be version 1.X of automake, until I say otherwise"

Now before I can implement this master plan, I need to fix all the packages that still build depend on "automake"[1]. To proceed with this I'd like to file wishlist bugs (with patches) against these packages one week from today. One week after that, with the Release Team's blessing, I'd like to start NMUing as much of these packages as I can. Once that is complete, I'd like to make the transition and raise the severity of any of bugs that remain.

Bug Filing

Please file bugs with wishlist severity. Make any bug you file block 376047.

Bug title: Please stop Build-Depending on automake

Bug header text:

The automake maintainer is working towards reclaiming the automake
package name, which currently rests on automake1.4, the oldest version
of automake. Your package Build-Depends on automake, hence this bug
report. Please see http://wiki.debian.org/AutomakeTransition for more
information on this transition.

Text for unneeded automake dependency:

It appears your package does not use the automake package in the build
process. This is normal, as most packages don't require automake at
build time. The attached patch removes the build dependency.

Text for updated automake dependency:

Your package appears to work with the latest automake1.9 package. 
Attached is a patch to update the build-dependency.

Ubuntu has a complementary page: https://wiki.ubuntu.com/AutomakeTransition


CategoryDeveloper