Bob Proulx wrote: > 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?
I ran the following command to create a list of packages that Build-Depend upon "automake". This produced the names of 98 packages in Sid today. grep-dctrl -F Build-Depends automake /var/lib/apt/lists/http.us.debian.org_debian_dists_sid_main_source_Sources | grep-dctrl -v -F Build-Depends -e 'automake[n1]' -n -s Package I ran the following command to create a list of maintainers of these packages. This produced the names of 71 maintainers in Sid today. grep-dctrl -F Build-Depends automake /var/lib/apt/lists/http.us.debian.org_debian_dists_sid_main_source_Sources | grep-dctrl -v -F Build-Depends -e 'automake[n1]' -n -s Maintainer | sort -u I did not feel the need to include those lists here because anyone can use those commands to generate that list on the fly. I spot checked two packages (gconf and time) and neither of those two ran automake during package build. However they do patch both source and derived files and suffer from the well known problem that timestamps are not set on patched files and therefore a race condition exists which may cause the autotools to be run to bring those files up to date. They probably depend upon the autotools just for the case when this condition is triggered without really understanding the underlying timestamp problems. In these two cases it would be better to touch the files up to date to ensure timestamp ordering of files and then remove the build dependency upon the autotools entirely. For my test I changed "automake" to "automaken" and both of these packages built without issue. Although those two did not call automake explicitly I am sure that others in the list do. At least I hope they are not all as silly! Updating the automake package to change the alternatives priority will not immediately break any of these packages. Those are all already built and installed in the archive. Those deb files will continue to be installable. It would only make them FTBFS upon the next upload of a new version of the package. However upon trying to recompile them for a new architecture such as amd64, if it ever is allowed to enter Sid, it would be FTBFS then. Hopefully amd64 will eventually become part of Debian and so we should definitely address the issue. Bob
signature.asc
Description: Digital signature
