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

[Ignacio Vazquez-Abrams]

On Sat, 2005-04-09 at 06:46 +0200, Ralf Corsepius wrote:
> 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.

It still works on i386. I suppose we'll see if it still works, or rather
if it plain and simple _works_ on x86_64.

> > > (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.

You aren't wrong, but I'm not completely sure that justifies an almost
100% size increase. If there are any ways to reduce the size of the
patch then I'd be interested in hearing them.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/scm-commits/attachments/20050411/941022da/attachment.bin