>>>>> "Havoc" == Havoc Pennington <[EMAIL PROTECTED]> writes:
Havoc> I'm wondering if we could convince you and the autoconf guys to Havoc> think about making incompatible autotools releases install in Havoc> parallel. I think this idea makes sense. It does seem apparent that we need to let people install some 1.4 and some 1.5 at the same time, due to the many incompatibilities. I personally reset PATH depending on what I'm working on, but that would be painful for projects that use a mix. Havoc> Also, in the spec file I rename automake to automake-1.4, Havoc> aclocal to aclocal-1.4, automake to automake-1.5, aclocal to Havoc> aclocal-1.5, and symlink automake to automake-1.5. I provide Havoc> versioned executables in both RPMs because those are probably Havoc> the best ones for other packages to refer to - so the packages Havoc> won't need to be changed when automake-1.6 appears and gets the Havoc> "automake" symlink. What do you mean by "versioned executables"? I think renaming the directories in $(datadir) is fine. But I'm not as sure about renaming the executables by default. I think I'd prefer to simply install as `automake', and let package maintainers use `--program-suffix=-1.5' (or equivalent) in their spec files. What do you think of that? Havoc> People seem to have an aesthetic reaction against including the Havoc> version number in the name of everything at first I guess I'm included in this category. I'm willing to be convinced though. One issue is what we put in the rebuild rules in the Makefile. We'd have to put the version there. That's a potential problem if, say, you move from using 1.5 to 1.5.1. You'd have to re-run automake by hand, and your package would depend on the precise release. I think the rebuild rule problem is even worse if autoconf is versioned. Where will the version info come from? A problem with having aclocal look in $(datadir)/aclocal by default is that we'll end up picking up 1.4 macros for a 1.5 install. I guess proper ordering of the `push's will handle this. We're planning to do a prerelease soon, followed shortly by 1.6. I'd like to get this resolved before then, assuming the above issues (and any more we think of) are tractable. Tom