On Thu, Oct 17, 2013 at 08:46:27PM +1030, Ron wrote: > And sometimes, updating autoconf "at random" actually breaks things, > sometimes subtly (to be fair this seems to happen less often over the > last few years now - but I have the scars of being burned by that too, > and _always_ review the diffs when it is updated before trusting them).
I'm not talking about updating autoconf output, though. I'm talking about updating config.guess and config.sub, which have some of the best compatibility records of anything in the archive. I've never heard of any bug caused by updating those, ever. > I'm not unsympathetic to the work and pain of porters bootstrapping a new > arch, but any 'solution' that is Debian-specific, isn't really a solution > at all, it's just an SEP field. There are other distributions who update config.guess/config.sub in their packaging too. I would say that *both* upstream and distributions need to handle this, realistically; but I don't think the lack of upstream handling it should hold back distributions. > If you really want to fix this for new ports, maybe we need a tool to scan > the archives and report these things before they become the bottleneck for > porting work. That just moves the manual work earlier (filing bugs, discussing them with maintainers, and NMUing when they ignore them is still quite a bit of manual work when you compare it with having all the packages just update themselves automatically); it isn't a fix. > Lintian does already have a "too old" check -- but it doesn't > actually bark about what would _really_ break (which 90% of the time is > something utterly obscure that Debian won't run on anyway). Um, well. As a point of information: Tag: outdated-autotools-helper-file Severity: normal Certainty: possible Info: The referenced file has a time stamp older than April of 2012 and the package does not build-depend on autotools-dev or automake and therefore apparently does not update it. This usually means that the source package will not build correctly on ARM64, for which a Debian port is currently in progress, and may not support other newer architectures. . For packages using debhelper, the tools from the dh-autoreconf package should handle this issue. cdbs will automatically update these files if autotools-dev is installed during build, but the build dependency on autotools-dev is still necessary. . Otherwise, read /usr/share/doc/autotools-dev/README.Debian.gz (from the autotools-dev package) for information on how to fix this problem. Lintian's threshold is generally only updated when there's a specific relevant new port. It helps, but it's not good enough since many of the problematic packages simply aren't uploaded at all often enough so their maintainers tend not to notice; and I fundamentally disagree that "let's source-upload half the archive" is a sensible way to handle new ports, even if those uploads are spread out. Not enough people garden their pages on lintian.debian.org routinely enough for this not to be a horrendous pain for porters, and we still have the problem of MIA maintainers. Yes, it's true that some packages require manual porting, but those are statistically rare and often have other indicators (e.g. a specific limitation in their Architecture field). > Anyhow, I'll close this one if you've confirmed the current package is > ok, but I don't want you to think I don't care about your pain. On the > contrary, I think we need a _better_ solution than what this patch does > to lay the groundwork for common problems seen when porting new arches, > and I'm pretty sure that for this specific problem, lintian already > implements 99% of what you'd need. I'm a Lintian committer, albeit a somewhat dormant one; I respectfully disagree that it can ever deal with this problem adequately. Still, at least some other maintainers are switching to autotools-dev in response to my patches, so that's reducing the pain for the next time round. I wasn't expecting to be able to persuade everyone. Cheers, -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
