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

Re: Packaging a library that requires cross-compiled code

[Josselin Mouette]
> Given that especially autoconf introduces serious incompatibilities
> between minor releases, this is simply not feasible because it would
> trigger hundreds of FTBFS errors each time a new autoconf version is
> uploaded.

So it sounds like you're saying that, although we ship source code to
our users, we _assume_ that the source doesn't actually build with our
tools, so we have to also ship precompiled code to work around this.
To me, that's a poor attitude for a distribution that focuses on
providing users with access to source.  What use is source code if it
can't be hacked on and rebuilt?

I think we should have a little bit of faith in our autoconf maintainer
not to introduce incompatible versions without changing the name.  This
was already done for autoconf2.13 -> autoconf2.50 (the latter since
renamed to autoconf).  If he uploads a version of autoconf that breaks
other builds, the appropriate response is to file a bug.  That is what
we do for gcc.  (Sometimes the response is "too bad, gcc is changing to
be more strict, you'll have to fix your package", and yet, the world
somehow fails to end.)

Honestly though, I haven't seen autoconf break my packages for a very
long time - I can't even remember last time it happened.  (It might
have been autoconf2.13 -> autoconf2.50.)  Were you thinking of
automake, perhaps?  automake changes much more frequently, which is why
we have so many versions in the archive, so you can use a version that
won't break your builds.
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Attachment: signature.asc
Description: Digital signature

Reply to: