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

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



On Mon, Feb 18, 2008 at 12:39:29PM -0800, Chris Waters wrote:
> But honestly, I think our job is to deliver full source and binaries.
> I _don't_ think we necessarily have to exercise every bit of the
> source (e.g. the .am files) on every build.  In fact, my primary
> objections to the java example would be a) that it confounds user
> expectations, and b) that it would result in huge diffs.  I'm not sure
> that either of those objections would apply to the autoconf case.

At least the huge diff does, that's one of the documented (in
autotools-dev's README.Debian) downsides of not running autotools during
package build.

> > 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.
> 
> I think there's a big difference between recompiling from source as an
> end user would do and (re)generating _everything_ as an upstream might
> do.  I suspect the ultimate question here is: does Debian serve as a)
> a proxy for the user, generating binaries so they don't have to, or b)
> as a proxy for upstream?  I tend to lean towards the former position;
> it sounds like you lean towards the latter.

Probably, although I'm not sure who we're proxying from and to then. ;-)

I think providing binary packages which work to users is certainly a
very important part of Debian.  However, that's not everything.  We also
want to keep it free, and one important aspect of that is that we
provide source packages which work as well.

To me, a "working" source package is the complete source plus build
rules (which work ;-) ) for that source.  And that's all the source, not
just a part of it.

Of course, the suggestion to add a debian/rules target which does this
which doesn't have to be run during the normal build process would work
for this as well.  One problem I have with that is that it'll be much
less tested.  This can be fixed by running automated testing, as also
suggested, but I think it will still mean that we will have packages
which can't be compiled from source.  Another problem is that the normal
build rules will still generate a huge and unreadable diff.gz.

I would therefore still prefer to build everything from source.  However
a recommended (or even mandatory) extra target to at least be able to do
it would be acceptable to me.  That doesn't solve the "what should the
clean target do exactly" problem, though.  Is "remove all files which
have been changed during the build" an acceptable answer to that?  If
that means autotools must be rerun during normal build (which I think
will be the case sometimes), is that acceptable to most people?

As a sidestep, I think this target may actually be legally required for
GPL (at least 2 and 3) licenced code.  They say

	For an executable work, complete source code means all the
	source code for all modules it contains, plus any associated
	interface definition files, plus the scripts used to control
	compilation and installation of the executable.
(version 2), and
	The "Corresponding Source" for a work in object code form means
	all the source code needed to generate, install, and (for an
	executable work) run the object code and to modify the work,
	including scripts to control those activities.
(version 3).

In other words, build rules to generate the binary from source must be
present.

If upstream doesn't normally ask from users that they regenerate all
files, that doesn't mean that we should make it as hard for the users as
well.  Because that's the main result of not running autotools IMO: it
makes it harder for the user to make use of the sources.  I think this
also has to do with:

> Well, I see one big difference.  I often get patches from downstream
> to configure.

Perhaps this is because when running debian/rules that's the file that
is used as the source.  If any other file would be changed, they should
include instructions for how that change can be made part of the
package.  (In the simplest case a list of extra build-depends.)

> But to me, this indicates that downstream often considers the
> configure file to be a readable source format.  This cannot be said of
> a uuencoded binary.  I think that's an important distinction.

I do agree with this, though. :-)

> Bottom line: it sounds like you think the java example is
> fundamentally wrong;

Indeed.

> I merely see it as flawed, awkward and hard to maintain: a bad idea in
> general, but not necessarily wrong.

Interesting...  I didn't expect Debian people to disagree with me on
that...  (Just to be clear, that's saying something about my
expectations, not about your opinion being wrong or anything. ;-) )

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: