[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#397939: Lintian: outdated-autotools-helper-file



On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:

> The fact that there exist packages which work properly without
> recompiling from source doesn't mean it's a good default.  IMO the
> default should be to always compile from source.  Yes, that means hassle
> for the packager; it's pretty much the whole task of packaging.

It's probably worth bearing in mind that there are quite a few people
out there who use autotools for want of a standard alternative and are
either indifferent to it or actively dislike it.  Often people have been
burned by the version incompatbilities in the past and try to avoid
having anything to do with it - I've seen people do things like check
the generated files into their VCS to avoid dealing with the churn.  I'm
not sure how prevalent this is it is an issue.

> > In other words, this proposal will have the effect of requiring that
> > Debian maintainers become experts in the Autotools before being able
> > to upload policy-compliant packages again,

> Not at all.  Autoconf is pretty stable, so I suppose you're talking

Not as stable as, say, C by a long way...

> then IMO it's totally reasonable that that weirdness is in debian/rules,
> so users can see what's happening, if they want to.

OTOH if the standard Debian build process jumps through unusual hoops
like forcing regeneration of all the autotools files that makes it less
useful as a guide for the things you'd actually want to do in the normal
course of affairs.  I know I've found Debian packages very useful for
that when doing things like working on programs for upstream purposes or
for non-Debian things like cross development.

> > I'm sure that that would make the security team's life a lot harder,
> > for instance

> Perhaps you mean that lots of bugs pop up when "automake" increases its
> version?  In that case I apologize for being unclear; I thought it was
> commonly known and agreed upon that you should always build-depend on
> the versioned package.

If you're willing to do things by forcing a particular version in the
general case then this sounds more like something that could be checked
outside the standard package build process.

If you're keen on introducing this I'd suggest doing some work to see
how much effort would be involved in doing so.

> Not at all.  If it's optional, it's likely that many packages will not
> have it.  Also, if the build system doesn't use it by default, it is
> likely that many of those targets are never tested and don't actually
> work.

We already have regular tests for things that aren't caught by the
normal build processes, this could be checked in a similar fashion.

> Also, considering the bug we're writing to, what would you propose that
> the clean target should do?  "Remove all generated files, except the
> ones that are generated by autotools"?  I can't properly express how
> completely wrong I find such an exception when written in Policy...

Personally, I expect the package to restore things to the state they
were in the distribution tarball.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."



Reply to: