Re: Cross Distro Spec Files

["Greg M. Kurtzer" <greg runlevelzero net>]

How about a script or hack to an existing build-tool (jhbuild or gargnome)
that will take a spec file template and use that to create all of the specs
for the packages?

For cAos Linux, we use mezzanine (previously the VALinux autobuild system)
which can build SPEC's for the standard ./configure&&make&&makeinstall type
source trees. Perhaps that can be used as a base and then just wrap it with
ordering and the spec template?

Regarding the package names, what I would like to see is not what I think will
work... I would like to see the upstream names used for the primary packages
(eg. gtk+), and then compatibility libs or the non-default package versions
having the versioned nomenclature (eg. gtk1). I know this isn't realistic, so
I would think that a name file should be taken into the build script (eg:
gtk+=gtk2, glib=glib2, etc...).

There will also need to be a master dependency file for both requires and
buildrequires. This can then be used for build ordering as well I think.

Unfortunately I would have to agree with Christian, there are way too many
differences to make *clean* maintainable specs for the main distros. I also
agree that utilizing rpmbuild defines will not work with the autobuilders that
we use (mezzanine). Perhaps a SPEC/SRPM generation script is the next best
thing?

On Wed, Jun 15, 2005 at 04:50:27PM +0200, Christian Lohmaier wrote:
> Hi *,
> 
> first of all it is good to see that the project is not dead :-)
> 
> On Sun, Jun 12, 2005 at 08:30:29PM -0400, Luis Villa wrote:
> > On 6/12/05, James Ogley <james usr-local-bin org> wrote:
> > > I'm sure people have seen Luis' comments on Planet GNOME about improving
> > > packaging, well, I've put a first draft of notes on X-Distro .specs
> > > online:
> > > http://live.gnome.org/CrossDistroSpecFiles
> > 
> > Cool! I didn't realize it could be done that straightforwardly in the
> > spec file. 
> 
> I don't think this is straightforward.
> True, the example above is not very complicated, but the example is not
> realistic.
> 
> 1st of all: adding hacks for sepecific distributions will classify the
> distributions in 
> * supported
> * will break soon
> * not supported
> 
> 2nd: just adapting the target-paths is not what it takes to support a
> distro.
> You'd have to maintain different files sections as well, and I don't
> even mention the different requirements..
> 
> The main problem is that the package-maintainer doesn't know every
> distro - he probably only knows one or two. So he cannot properly
> maintain the specfile. It will break for a bunch of "targets" (distros)
> very likely.
> 
> > It would really rock if someone with RH packaging-fu wanted
> > to collaborate with James on a cross-distro spec file for some of the
> > basic stuff in jhbuild- maybe gucharmap and the core dependencies?
> 
> I certainly won't because I think a cross-distro spec is one that
> doesn't need switches. I think adding these hacks (and removing rpmmacro
> definitions like "%configure" with verbatim replacements ("manually" set
> cflags and stuff) is the wrong way.
> 
> Distros will build their own packages anyway.
> 
> I think first we need an agreement on the names of the individual
> packages. Naming packages differently depending on the distro is not the
> way I'd go. You probably need the package in the requires of another
> one. Maintaining this is not fun at all.
> 
> Another thing is: What helper macros are allowed in the spec? While
> %find_lang is very common, %install_info & %remove_info may be not.
> This is not a problem for binary packages, but the intermediate goal is
> to allow for packages to be *build* by the user.
> 
> Then a policy regarding pkgconfig files is needed (always put them into
> /usr/lib/pkgconfig or allowing them in a different prefix - having then
> to deal with setting environment-variables during build)
> Policies regarding .desktop-files and mime-package files, icons.
> Basically same as above: Either force them to go to /usr/share/... or
> allow them to be placed in another prefix (then having to adapt
> gnome-menus/gnome-vfs to have a look in that other prefix.
> 
> You could handle exeptions from the policy set by the gpp with a
> build-root-policy (os_install_post, can move the files, modify
> configuration-files) in combination with the %configure makro (would set
> the pkgconfig-paths, etc) (this is only for special-purpose, not for the
> mass of users)
> 
> Is the person that builds & installs the package expected to configure
> rpm's install_script_path to include the prefix? Or must the specfile
> compensate for different prefixes?
> 
> Only because of the above decisions that have to be made, I'm against
> X-Distro specs that work via distro-switches.
> 
> If you want to do support different distros, create a distro-specific
> package that either defines a special macro that can then be used in the
> individual rpms or include specific helper-programs that then do the
> distro-specific stuff.
> 
> All "fu" that is defined within the specfile is considered harmful
> (well, at least by myself)
> 
> A gpp provided spec should be simple as possible and make use of macros
> that can be overriden by the user that builds the package.
> 
> ciao
> Christian
> -- 
> NP: Kashmir 9:41 - Break Free
> _______________________________________________
> Gnome-packaging-list mailing list
> Gnome-packaging-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-packaging-list

-- 
Greg M. Kurtzer
http://runlevelzero.net/
http://caosity.org/
http://warewulf-cluster.org/

        -- Do not look anywhere for truth, for all that is needed is to refrain 
                                                from allowing concepts to arise