Bug#746514: Autoreconf during build
+ If your package includes the scripts <prgn>config.sub</prgn> and
+ <prgn>config.guess</prgn>, you should arrange for the versions
+ provided by the package <package>autotools-dev</package> be used
+ instead (see <package>autotools-dev</package> documentation for
+ details how to achieve that). This ensures that these files can
+ be updated distribution-wide when introducing new architectures.
Please don't word policy that way.
This does not solve the problem, only hides it, and it's the way to
forget the problem instead of actually solving it.
With or without this policy, porters should have to hack packages
anyway, so this is only useful for packages which are not updated
upstream often enough.
I think such a strong requirement ("should") does not belong to policy.
Make a recommendation if you wish, but making mandatory that those
files are updated at build time would be like making mandatory the use
of debhelper (which we don't, because we want to keep the freedom to
not use a helper package).
Those files were created with portability in mind. If we have to
update those files each and every time at build time, there is a clear
design flaw. Once again, we should talk with GNU people about this
problem.
(Or do something that this proposed policy does not encourage, which
is to continue to flood them with reports saying "Please update
config.* files", maybe that way they would realize that the current
status is highly suboptimal).
My suggestion:
Packages using config.sub and config.guess should ship recent
versions of those files, or, alternatively, arrange for the versions
provided by the package <package>autotools-dev</package> to be used
at build time.
BTW: The most recent version of those files are now GPLv3 + exception.
Perhaps we should say something in policy about ensuring that the
package may be built with the new files instead of automatically and
blindly doing so.
Thanks.
Reply to: