Re: The automake issue, and why crippling 1.6 is a bad plan
On Thu, 13 Jun 2002, Joseph Carter wrote:
> On Thu, Jun 13, 2002 at 05:39:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > Lots of packages need to make changes to configure.in, I have to make
> > > changes to the one in SDL, for example.
> > Then read /usr/share/doc/autotools-dev/README.Debian.
> > Ignorance is not an excuse anymore, go fix the package. Get the
> > cyrus21-imapd source package if you need any help. Hint: cyrus builds
> > straight from CVS, using cvs-buildpackage, and it still manages to generate
> > configure only once, and not bother the users, nor build-depend on autoconf.
> Those who would call others ignorant should first be not so themselves.
Right. So I won't accuse anyone of being ignorant.
> The configure.in shipped with SDL upstream causes lintian errors about
> things which have been a violation of policy at least as far back as I can
> remember. My package fixes this in configure.in and then regenerates the
> build scripts.
You said the magic word.
They are _scripts_. That means you can put them in the diff, and generate
them while building your _source_ package. No need to build
configure-scripts as part of building your binary package.
> This is not an accident or an artifact of dpkg-source,
> it's an intentional act performed to comply with Debian's policy,
State me the part of policy that requires you to regenerate your
configure-script as part of 'debian/rules binary', please?
> the one
> thing that keeps some people using Debian despite all of the bullshit we
> have seen come out of places like this list over the past year or so.
> I refuse to defy Debian policy because you don't like build-deps on
> autoconf and automake.
He's right to not like it. It's a mess.
If you're concerned about automake trying to regenerate configure and
friends because patch doesn't care about timestamps, then 'man touch' is
wouter at grep dot be
"Human knowledge belongs to the world"
-- From the movie "Antitrust"
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org