bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make dist


From: Bob Proulx
Subject: Re: make dist
Date: Thu, 17 Nov 2005 00:10:42 -0700
User-agent: Mutt/1.5.9i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]