Re: Cross Distro Spec Files

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 <[email protected]> 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