* Kamila Szewczyk ([email protected]) wrote: > PS. To elaborate further on your question from the first e-mail, > > The version pin is deliberate and is here to stay, sorry. However, > libtool shouldn't need rebuilding for every automake release, and it > will not once the fixes for the bugs that I identified make it into > release(s). aclocal.m4 is *not* independent of automake and making it > into a separate package would be a very bad idea conceptually, and also > it would not resolve the issue. To reiterate, the version check would > be completely harmless if aclocal wasn't mistakenly called because of > the bug pointed in the previous e-mail. > > > Should we be making aclocal its own package and have the versions > > co-installable? > > Co-installable versions are already supported by upstream automake. > Everything is versioned except bin/aclocal, bin/automake, their man > pages, the info manual, share/aclocal/README and the amhello example, so > Debian could in principle provide automake-1.18 and automake-1.19 side > by side, with alternatives for the unversioned names.
From the Debian perspective we have taken advantage of this in the past and had multiple coinstallable versions of automake when compatibility between versions was worse. We just haven't the last few releases because there haven't been significant compatibility regressions. If it turns out there are enough problems we can do it again. > BTW, automake 1:1.18.1-4 declares "Provides: automake-1.17", which looks > wrong. That was wrong and was removed in the latest upload of 1:1.19-2. -- Eric Dorland <[email protected]> 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
signature.asc
Description: PGP signature
