devel/lock-keys-applet lock-keys-applet.spec,1.8,1.9

[Ralf Corsepius]

On Fri, 2005-04-08 at 15:22 -0400, Ignacio Vazquez-Abrams wrote:
> On Fri, 2005-04-08 at 20:34 +0200, Thorsten Leemhuis wrote:
> > Am Freitag, den 08.04.2005, 14:08 -0400 schrieb Ignacio Vazquez-Abrams:
> > > Modified Files:
> > > 	lock-keys-applet.spec 
> > > Log Message:
> > > I'm not very experienced with autotools, so if I screwed up feel free to tell me.
> > 
> > Here we go:
> > 
> > You forgot to BR automake, autoconf, libtool.
> 
> Whoops. I knew I forgot something.
> 
> > And there was/is a discussion on "don't use automake, autoconf, libtool
> > in spec files cause it will break sooner or later". See archives.
> 
> Will do.
> 
> > A solution some of us currently using in several packages is to do the
> > 
> > libtoolize --force && aclocal-1.9 -I m4 && autoheader && automake-1.9
> > && autoconf

The package ships with automake-1.7.2/autoconf-2.57-generated files.

As automake-1.9 isn't necessarily compatible to automake-1.7,
regenerating the files with automake-1.9 is not without major risks.

If you're sure this package's configuration still works with
automake-1.9, then there is nothing wrong with using automake-1.9
otherwise you might prefer using automake-1.7.

> > (or something like that), remove autom4te.cache after it and prepare a
> > patch of it. See for example in the uim or libgnomemm26 spec-file.
> 
> I looked at the approach taken by libgnomemm26, but it results in a 200k
> patch file after bzipping. That's almost as large as the source tarball
> of l-k-a itself.
Nevertheless, IMO opinion shipping a diff instead of BR'ing the
autotools is still preferable, because it reduces the risks of silently
breaking something, because dynamically generating autotool generated
files render builds non-deterministic.

Ralf