Re: Universal spec.in's

[Gregory Leblanc <gleblanc cu-portland edu>]

On 30 Apr 2001 04:11:01 -0500, David Elliott wrote:
> Dan Mueth wrote:
> 
> > I've been thinking about how we could set up a system to produce RPM's for
> > various RPM-based distributions...
> >
> > How hard would it be to create an autoconf macro that detected your
> > distribution and defined a set of variables which get substituted into the
> > spec file at configure time?  It seems like it would be a bit of work but
> > quite doable.
> 
> First off, this really would suck because you'd have to untar the package,
> run configure, then grab the spec file out of it to make the rpm.  That is
> not cool.  It's bad enough that there is already a .spec.in for the packages
> and autoconf generates a .spec.  Although that is not such a bad thing since

Why is having a .spec file generated from .spec.in a bad thing?  It
actually offers a lot more than just automatically updated version
numbers.  With Nautilus and gnome-core (those are they only two that
have been worked on, so far), it also tracks the versions of things that
it requires, like gnome-vfs and ORBit.  When gnome-core requires a newer
version of ORBit, the authors can just go in to configure.in, and change
the version number that's required by editing 1 line at the top of the
file, and possibily updating the ORBit test.  They don't have to worry
about the gnome-core.spec file getting out of date, because it's
generated via configure, and will always have the right version.  That
got a bit long, sorry.

[snip comments on file locations]
> For the most part the main problem you are going to have with different rpm
> based distros is different libc and other library versions.  But that is only
> an issue for binary packages.  Source packages should be able to be rebuilt
> on any RPM system, and the only differences you will likely encounter is
> where stuff is installed.  Like /usr/man vs. /usr/share/man.

Actually, at least as large of a problem is the issue with there not
being any centralized naming policy for RPMs.  SuSE doesn't have a
"gtk+" rpm, they have a "gtk" RPM.  I haven't found any good way around
this yet.  I think that problems that are caused by libc and other
linking issues should be fairly easily solved by simply rebuilding from
the source packages.
    Greg

-- 
Troll, troll, troll your post
Gently down the feed
Merrily, merrily troll along
A life is what you need...