Eric Dorland wrote: > Bob Proulx wrote: > > Eric Dorland wrote: > > > Scott James Remnant wrote: > > > > However the priorities of the /usr/bin/automake alternative still make > > > > automake1.4 the best version. > > > > > > > > Could this be changed so that the best version is now the most recent, > > > > rather than the oldest? > > > > > > I'd like to do that, but last time I checked, a lot of packages that > > > call "automake" in there build-dependencies expect automake to be > > > automake 1.4. If packages stop build-depending on automake I could > > > certainly change this. > > > > This bug was file before the last stable release. Now that there has > > been a stable release is is possible to make changes now so that the > > next stable release will have the most recent version the default > > instead of the oldest? > > I'm trying to think why I objected to this before, but I'm not sure > what I was thinking.
Time goes by and it is sometimes hard to get back into the same mental state. This bug is old enough that I think much of the environment around it has changed significantly enough that previous issues are completely different now. I think it needs to be looked at fresh today and dealt with in the current environment. > The only problem with this change is that there are still packages > that Build-Depend on automake, and if I make this change, those > packages will fail to build on systems with multiple automakes > installed (and the alternatives haven't been touched manually). I'm > not sure if that's really a problem or not. For Etch I believe that any package that Build-Depends on automake (which is 1.4p4) needs to be updated. Upstream considers that version very old and obsolete and I think most developers would also agree. It is unfortunate that the API is not fully backwards compatible. But it is not. Some changes may need to be made to work with the newer autotools. There is a strong split of reasoning of developers as to whether to run the autotools at package build time and then Build-Depend upon the autotools. One group thinks this should never be done. The other group thinks this should always be done. This has been debated often enough that I think both groups are right in their own reasoning. I don't think it would be productive to try to convince one group to the other group's thinking at this time. For now let's just accept it and move on. The typical reasoning put forward as to why to use the autotools at package build time and then to Build-Depend upon them is so that the package will be guarenteed to build from full source in Debian. I think that is a defensible argument. If this is the case then packages which do so much be willing to upgrade as the build environment in Debian is upgraded. This keeps the package alive and buildable from full source as is the desire. Therefore I think it is reasonable to expect that packages that Build-Depend upon automake will need to be modified in order to adapt to the proposed change. (And of course packages in the other group which do not run the autotools at build time but use the static built files and do not build depend upon automake will not be affected. But they will also not really build from full source either. They might not have before. But let's not go there at this moment.) I think the best case would be to have those packages that build depend upon automake to upgrade to work with a newer automake version. Also an okay result would be to have packages that build depend upon automake change to build depend upon automake1.4 and also to call automake1.4 explicitly in their debian/rules file at package build time. Either case resolves this problem acceptably well without a major thrash. Comments? Bob
signature.asc
Description: Digital signature
