On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote: > Let's compare it with a Java program. Would you consider it acceptable > for the packager to build it, uuencode it, put it in the diff.gz and > from debian/rules just uudecode it, instead of regenerating it?
Well, I see one big difference. I often get patches from downstream to configure. I, of course, make sure to apply them to the appropriate .am (or whatever), as well as forwarding them upstream. 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. Whether that distinction is sufficient to justify a different set of rules, I reserve judgement on at this time. 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. > 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. Bottom line: it sounds like you think the java example is fundamentally wrong; I merely see it as flawed, awkward and hard to maintain: a bad idea in general, but not necessarily wrong. -- Chris Waters | Pneumonoultra- osis is too long [EMAIL PROTECTED] | microscopicsilico- to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
