Charles Levert wrote: > * Tony Abou-Assaleh wrote: > > Found the problem. The automake version was 1.4, which caused a few things > > not to work. The syntax of some macros changed in later versions of > > automake.
I recommend the following for the current stable Sarge release. sudo apt-get install automake1.9 sudo apt-get remove automake1.4 > Looking at the packages.debian.org web site, > I see that stable, unstable, and testing all > have 5 packages each for automake: 1.4, 1.6, > 1.7, 1.8, and 1.9. So which ones gets to have > the automake command name first in the PATH in > a default Debian install? The automake packages are all versioned and install as unique names /usr/bin/automake-1.9 and so forth enabling multiple versions to be installed simultaneously. The Debian oldstable release included 'automake' (which was 1.4p4) and 'automake1.5'. The current Debian stable includes 'automake1.4' through 'automake1.9'. The new packages "conflict" with the old 'automake' and will force it to be removed if installed. The Debian alternatives (a policy mechanism managing symlinks from one program to another) are used to manage which program gets to be called as simply /usr/bin/automake with no extension. The highest priority package wins. The priority is as one would expect for automake1.5 through automake1.9 with the latest one being the default if it is installed. I have automake1.9 installed along with the others and version 1.9 is the default. But automake1.4 is uniquely different and arguably broken. It has the highest priority of all of the packages. If automake1.4 is installed then it becomes the default. See this reference for a discussion. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228604 The summary of that discussion is that many packages depended upon the old automake1.4 behavior and the maintainer was concerned that there would be too much system package build breakage if the default was changed. But that was quite some time ago, before the last stable release, and perhaps some traction could be achieved on this today for the next stable release. In any case, if automake1.4 is installed it is the default automake by default. I would recommend that it never be installed. But some packages will build-depend upon it and it will get pulled in to satisify the needs of those packages if needed. Then it is necessary to notice this and to remove it afterward. > My system has a /etc/alternatives and a > /usr/sbin/alternatives for this sort of things, > but strangely just a hard link is used between > /usr/bin/automake and /usr/bin/automake-1.7 > instead of relying on them. That seems like something locally done on your system. It is not normal. I have automake1.7 installed on my system and the alternatives for it are using a symlink as normal. You might want to fix up your system and return it to normal. The following commands may be useful in this regard. But I have not tested the correction action when there is a hard link in place so use caution. I would be inclined to break the link first since it is unusual. update-alternatives --display automake sudo update-alternatives --auto automake Just for completeness I will say that you can configure the alternatives interactively with --config and explicitly with --set. sudo update-alternatives --config automake Or: sudo update-alternatives --set automake /usr/bin/automake-1.9 I recommend that for automake it be set to auto so that newer packages will automatically become the default when installed. But of course the local configuration is completely up to the local admin. Bob
