Should there be BuildRequires for perl/libtool/auto*?

[Toshio Kuratomi]

Hi, I'm fighting with BuildRequires here and was wondering about the
auto* family of tools.  configure checks for them at build time and
during builds of some packages.  Are these tools actually needed for
the package to build (ie: should they be a BuildRequire?)

A related question:  If I change something up the tool chain (A
configure.in or Makefile.am) should I do my auto*'ing inside the .spec
or do it in my work area before hand and create a patch?  The latter
will generate a bigger patch, but it seems cleaner....

-Toshio
-- 
Toshio <toshio(a)tiki-lounge.com&gt;

[David Hollis]

On Sat, 2003-12-27 at 10:04, Toshio wrote:
>  Hi, I'm fighting with BuildRequires here and was wondering about
> the
>  auto* family of tools.  configure checks for them at build time and
>  during builds of some packages.  Are these tools actually needed for
>  the package to build (ie: should they be a BuildRequire?)
>  
>  A related question:  If I change something up the tool chain (A
>  configure.in or Makefile.am) should I do my auto*'ing inside the .spec
>  or do it in my work area before hand and create a patch?  The latter
>  will generate a bigger patch, but it seems cleaner....
>  
>  -Toshio
> From what I have seen, if you patch configure.in/ac or a Makefile.am, 
you should
call the auto* tools from the spec file - typically in the
build section from what I have seen.  In those cases, you should
probably supply a BuildRequires especially if you require specific
versions of the auto tools (autoconf >= 2.57 for example).

[Warren Togami]

David T Hollis wrote:
>  On Sat, 2003-12-27 at 10:04, Toshio wrote:
>  
> >Hi, I'm fighting with BuildRequires here and was wondering about the
> >auto* family of tools.  configure checks for them at build time and
> >during builds of some packages.  Are these tools actually needed for
> >the package to build (ie: should they be a BuildRequire?)
> >
> >A related question:  If I change something up the tool chain (A
> >configure.in or Makefile.am) should I do my auto*'ing inside the .spec
> >or do it in my work area before hand and create a patch?  The latter
> >will generate a bigger patch, but it seems cleaner....
> >
> >-Toshio
>  
> >From what I have seen, if you patch configure.in/ac or a Makefile.am,
>  you should call the auto* tools from the spec file - typically in the
>  build section from what I have seen.  In those cases, you should
>  probably supply a BuildRequires especially if you require specific
>  versions of the auto tools (autoconf >= 2.57 for example).  
>   
If you require a specific version of any package, then you MUST include 
an Epoch in that dependency.  If the Epoch is blank, then make it "0".

Warren

[Matthias Saou]

Warren Togami wrote :

>  If you require a specific version of any package, then you MUST
> include 
>  an Epoch in that dependency.  If the Epoch is blank, then make it "0". 
Why? Can you give a good reason to introduce "0" in every versionned
dependency? I can only think of reasons _not_ to :
- Keep things shorter, clearer thus easier to understand
- Not confuse the user with the arbitrary number that the epoch is when he
  gets a message like "Failed dependencies, requires foo >= 1.20"

Epochs are only used in corner-cases, why make them appear in the general
case at all?

I still don't think introducing a zero epoch everywhere is sensible nor
useful.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl
Load : 0.16 0.07 0.07

[Michael Schwendt]

On Sun, 4 Jan 2004 20:32:28 +0100, Matthias Saou wrote:

>  Warren Togami wrote :
>  
>  > If you require a specific version of any package, then you MUST include 
>  > an Epoch in that dependency.  If the Epoch is blank, then make it "0".
>  
>  Why? Can you give a good reason to introduce "0" in every versionned
>  dependency? I can only think of reasons _not_ to :
>  - Keep things shorter, clearer thus easier to understand
>  - Not confuse the user with the arbitrary number that the epoch is when he
>    gets a message like "Failed dependencies, requires foo >= 1.20"
>  
>  Epochs are only used in corner-cases, why make them appear in the general
>  case at all?
>  
>  I still don't think introducing a zero epoch everywhere is sensible nor
>  useful. 
With chosing the term "corner-cases" you remove every base for discussion.
You acknowledge that an explicit zero epoch can be useful, but at the same
time you pin it down to corner-cases which you don't specify. Suppose
someone wants to avoid problems with any such corner-cases. I'm not an RPM
expert, but I'm aware of problems like this:

# cat /etc/redhat-release 
Red Hat Linux release 8.0 (Psyche)

Suppose we've got a library sub-package "libfoo" which is created as
part of a "foo" src.rpm:

# rpm -qp --qf "%{epoch}:%{version}\n" libfoo-2.0-0.i386.rpm 
(none):2.0

In a new release, upstream decides to split off a library, starting with
an unstable pre-1.0 release:

# rpm -qp --qf "%{epoch}:%{version}\n" libfoo-0.8-0.i386.rpm 
1:0.8

# rpm -ivh libfoo-2.0-0.i386.rpm 
Preparing...                ########################################### [100%]
   1:libfoo                 ########################################### [100%]
# rpm -Uvh libfoo-0.8-0.i386.rpm 
Preparing...                ########################################### [100%]
   1:libfoo                 ########################################### [100%]
# rpm -Uvh libfoo-2.0-0.1.i386.rpm 
Preparing...                ########################################### [100%]
   1:libfoo                 ########################################### [100%]

[...]

Explicit Epoch 0 makes a difference:

# rpm -q --qf "%{epoch}:%{version}\n" libfoo
1:0.8

# rpm -qp --qf "%{epoch}:%{version}\n" libfoo-2.0-1.i386.rpm 
0:2.0

# rpm -Uvh libfoo-2.0-1.i386.rpm 
Preparing...                ########################################### [100%]
        package libfoo-0.8-0 (which is newer than libfoo-2.0-1) is already installed

--

[Michael K. Johnson]

On Sat, Dec 27, 2003 at 10:11:54AM -1000, Warren Togami wrote:
>  If you require a specific version of any package, then you MUST
> include 
>  an Epoch in that dependency.  If the Epoch is blank, then make it "0". 
Huh?

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/

[Alexandre Oliva]

On Dec 27, 2003, David T Hollis <dhollis(a)davehollis.com&gt; wrote:

>  From what I have seen, if you patch configure.in/ac or a
> Makefile.am,
>  you should call the auto* tools from the spec file - typically in the
>  build section from what I have seen. 
FWIW, I find it a very bad idea to run autoreconf or somesuch in spec
files.  The right way to do it, IMHO, is to bundle with the patch for
the configure.in/.ac or Makefile.am the patches for the generated
files (and maybe some additional touch statements), to make sure you
don't depend on the exact version of the auto* tools that you have
installed to be able to rebuild the package, which is how these tools
are meant to be used.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer