Re: About a mass bug report not based on Sid or Jessie.
Wookey dixit:
> +++ Paul Wise [2014-04-16 19:51 +0800]:
> > On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote:
> >
> > > What some people here try to do, update config.guess and related files,
> > > is, IMHO, just a hack. Sure, it will just work, but only for us (Debian).
[…]
> > Other distributors do the config.guess/sub dance by default IIRC.
>
> Certainly build-from-source distros like OE and gentoo do. Not sure
[…]
We do both in MirPorts (for MirBSD): update config.{guess,sub} is
only half the part though, you really also need to run autoconf,
autoheader, aclocal, automake usually. (In MirBSD I even swap out
libtool, but that’s because platform support is not upstreamed, and
even if it were, that’d be too late for the vast majority of the
software around because software uses libtool 1.5, or at best 2.0/2.1
not $current+1 which is where that’d end up.)
> * add autotools-dev to build-essential so it's always available for
autotools-dev is not enough, see above and below. But build-essential
is the wrong place: debhelper is not in it either…
Paul Wise dixit:
> On Thu, Apr 17, 2014 at 2:42 AM, Russ Allbery wrote:
> > Wookey writes:
> >
> >> So, where in debian should we put responsiblity for updating
> >> config.{sub,guess}?
> >
> > I lean towards being more aggressive than this and running autoreconf or
> > the moral equivalent on any package using Autoconf, by default. For that
Full ACK here, both with DD hat, and as advice from what I learned
porting software to MirBSD.
> Add a lintian warning for packages using autotools, debhelper compat <
> 10 and not using --with autoreconf.
As long as lintian will not trigger this warning for people not
using dh7 short style, agreed.
(How does one use dh-autoreconf manually, anyway? It’s a pretty
recent thing, never seen it… just B-D on it and call it before
running configure?)
On Wed, 16 Apr 2014, Guido Günther wrote:
> On Mon, Apr 14, 2014 at 05:10:40PM -0700, Steve Langasek wrote:
[…]
> > But I think we ought to switch to autoreconfing by default.
>
> I do too but I do wonder if this might make stable backports harder
> since newer autoconf macros might not be available in stable and we
> wouldn't have noticed (or cared) until rerunning autoreconf. So being
> able to easily turn it off would be nice.
Full NAK there: if adding dh-autoreconf produces errors (other than
bugs in dh-autoreconf or autoconf that make regenerating configure
with the method used by dh-autoreconf fail), your package is RC-buggy
because it does not build from the source that’s shipped in the archive.
If you need newer autoconf macros in backports, you can build-depend
on a backport of autoconf.
It’s kinda the same thing as “regenerate documentation at build time”
except not doing so for autoconf/automake/libfool is worse and has a
much higher potential for introducing problems.
One PITA here is that autofools versions are not upwards or downwards
compatible. In MirPorts, we solved this by hacking libtool 1.5 to also
work with automake 1.4 and autoconf 2.13, then packaging several ver‐
sions of autoconf and automake, which are coïnstallable, and allow the
package to select (between “old” 1.4/2.13 and “new”, which is 1.9/2.61
by default but allows e.g. 1.10/2.64 too.)
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Reply to: