Buildrequire: perl-XML-Parser (Was: Re: rawhide report: 20060531 changes)

[Tomasz Kłoczko]

Cc: to intltool developer.

Dnia 31-05-2006, śro o godzinie 14:56 +0200, Nils Philippsen napisał(a):
> On Wed, 2006-05-31 at 14:20 +0200, Tomasz Kłoczko wrote:
> > Dnia 31-05-2006, śro o godzinie 03:52 -0400, Build System napisał(a):
> > [..]
> > > gnome-keyring-manager-2.14.0-2
> > > ------------------------------
> > > * Mon May 29 2006 Alexander Larsson <alexl at redhat.com> - 2.14.0-2
> > > - buildrequire gettext and perl-XML-Parser
> > 
> > *All* this kind changes are incorrect.
> > BuildRequires for perl-XML-Parser must be replaced by intltool because
> > for exaple gnome-keyring-manager build automation do not uses directly
> > perl-XML-Parser but intltool and intltool uses perl-XML-Parser (yess
> > inltool acelocal macro display messages about looking for
> > perl-XML-Parser but it dosent matter).
> > 
> > Intltool must have Require not gettext but gettext-devel. IIRC Requires
> > rule for neccessary perl modules from perl-XML-Parser is autogenerated
> > so adding explicite in intltool spec Require rule for perl-XML-Parser
> > isn't neccessary.
> 
> Objection. I also have a package concerned by this (hwbrowser) and it
> (by itself) contains intltool scripts (no external dependency on
> intltool) which require perl-XML-Parser. Therefore this package requires
> "perl-XML-Parser" for building. Note that with packages using an
> external intltool YMMV.

OK you are right and I'm wrong.
Now I'm after looking on this closer.
Ab ovo .. libtoolize install in project tree intltool*.in files.
config.status generates from this in files
intltool-{extract,merge,update} scripts. Diffrence beetween .in fileas
adn generated seems is only in first line where is placed perl binary
path. And .. intltool package provides the same copy of this scripts
files with perl binary path in preable line.

For me current scheme using intltool look like performing some little
stupid things because:
- intltool and all .in files have the same requirements,
- looks like intltool is backward compatible because anywhere is
  required intltool is required minimal version,
- distributing copy intlook scripts as .in files it is plain waste of
  hard disks space and connections bandwitch.

Better will be change this to:
- from intltool removed intoollize scripts and .in files. Installed
  intltool package can contain only above three scripts with
  correct perl binary path (temporaty it can be changed to /bin/true
  link for not breaking some autogen scripts :),
- add to intltool for examle intltool.pc file which will allow detect on
  autoconf level intltool avalaibility and minimal version (all this can
  be performed by change IT_PROG_INTLTOOL aclocal macro so introduce
  this will not require some additional changes in each project which
  now uses intltool,
- during update desktop, schemas and other fiels use system avalaible
  intltool-* scripts,
- if in system are avalaible intltool-* scripts perl path detection can
  be dropped (perl-XML-Parser too) because all this detection was
  performed on intltool install stage (directly from tar ball or from
  dist rpm/deb/whatever package).

.. faster (on autoconf level), less consuming disks across the network,
simpler.

Also looks like performing above changes will do not require change on
each projects which now uses intltool. If next version intltool will use
this this can be backward compatible without installing new intltool in
system resources because current intltool package provides
%{_bindir}/intltool-{extract,merge,update} which can be used directly.

kloczek