Re: automake 1.5
On Mon, Oct 08, 2001 at 09:59:54PM +0100, Colin Watson wrote:
> On Mon, Oct 08, 2001 at 04:33:46PM -0400, Steve M. Robbins wrote:
> > On Mon, Oct 08, 2001 at 02:31:50PM -0500, Colin Watson wrote:
[ ... ]
> > > Otherwise automake might be run on a buildd that has an incompatible
> > > version of automake installed, and using 'Build-Conflicts: automake' to
> > > prevent that seems excessive.
Let's be clear about the problem we're discussing.
Certainly a package that build-depends on automake could be disturbed
by another version of automake.
Consider a package that DOES NOT build-depend on automake. I don't
see automake in the list of "build-essentials". Is it the case that
buildd machines typically have automake available when building a
package? If not, there is no problem; the problem can only arise if a
build daemon installs automake even when not asked to do so.
Moreover, the problem arises only when said automake is "incompatible"
with the package's source (e.g. Makefile.am). Let's give the automake
authors the benefit of the doubt: until demonstrated otherwise, I'm
going to assume that so-called "incompatibilities" arise from actual
mistakes in the upstream package sources. For example, relying on
internal automake details, patching automake- or libtool-generated
files, or the like. That is, they are relying on automake-1.4'isms.
So the problem arises when three things occur:
1. (a) the package build-depends on automake, or
(b) the build daemon installs automake even if not asked to, and
2. the package depends on automake 1.4 details, and
3. "automake" is automake 1.5.
Possible remedies include the following
1a. alter debian/rules to not require automake
1b. don't install automake
2. fix the package to work with automake 1.5
3. downgrade back to automake 1.4
Myself, I want to have automake 1.5 around, so I don't like option #3.
Granted, that is not a strong reason for Debian as a whole, but I
expect that we can make the other remedies work. Clearly #2 is the
long-term solution in any case.
I know that there are nearly 300 packages said to build-depend on automake.
But we still don't know how many will actually fail to build, and we don't
really know the reasons for the failure. I'm inclined to investigate
remedies #1a and #2 before giving up.
It may well turn out that a large number of packages are tricky to
quickly fix for automake 1.5. Perhaps introducing an "automake1.4"
package that such packages can build-depend on is a reasonable
compromise?
Any of the above will obviate any need to worry about time-stamp
ordering.
> > > Also, if you build without --enable-maintainer-mode, Makefile.in's
> > > dependencies will be disabled, so automake will never be run.
> >
> > That is only true if the configure.in uses AM_MAINTAINER_MODE which
> > isn't too common, although it may be that rather large projects (like
> > GNOME?) use it in all their packages.
>
> Is there a downside to using it? I know that various people have
> expressed a dislike for it in the past, but don't know the details.
Depends on your point of view. :)
As a developer (i.e. one who is mucking about with the .c files), it
is a royal pain in the ass that a change in Makefile.am does not get
picked up. So I never personally use AM_MAINTAINER_MODE.
On the other hand, from the point of view of an installer, such rules
*should* be irrelevant, so there is no harm in removing them.
Additionally, I think AM_MAINTAINER_MODE used to remove the
"dependency-tracking" rules (which used to require GCC, so people
complained). Nowadays, there is dependency-tracking support for a
number of compilers and it is not affected by AM_MAINTAINER_MODE.
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: