Cross Distro Spec Files

[James Ogley]

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

James

[Luis Villa]

Post by James Ogley
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
http://live.gnome.org/CrossDistroSpecFiles

Cool! I didn't realize it could be done that straightforwardly in the
spec file. 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
know there was some talk about doing this for libxml, but AFAICS it
didn't, so maybe this is the right time to get the ball rolling again.

Anyway, this definitely rocks- thanks, James-
Luis

[Christian Lohmaier]

Hi *,

first of all it is good to see that the project is not dead :-)

Post by Luis Villa

Post by James Ogley
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
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.

Post by Luis Villa
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

[Greg M. Kurtzer]

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?

Post by Christian Lohmaier
Hi *,
first of all it is good to see that the project is not dead :-)

Post by Luis Villa

Post by James Ogley
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
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.

Post by Luis Villa
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
http://mail.gnome.org/mailman/listinfo/gnome-packaging-list

[Christian Lohmaier]

Hi Greg, *,

Post by Greg M. Kurtzer
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?

I don't think this is possible. You may be able to create rpm-files,
sure, but this is not what I would consider a "good" one.

If you can create the logic to create the spec using a build-tool, you
could just create the real specs as well.

Post by Greg M. Kurtzer
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?

For the standard procedure, you'd just have the %configure, %make and
%makeinstall macros.

This is not what makes up an rpm...
If we just wanted to create rpms that contain merely the files, we could
start just know, without any special "magic".

The tough thing about rpms is to get the requirements right and to split
the package reasonably.
This reminds me of a point I forgot in my last mail: How should packages
be split? Base package and development package? Or a devel-static
package as well?

I used the very same dummy spec file for every gnome-package, only
adapting the files-section. Not much trouble. Only a few packages only
rely on the "destdir" install, almost every package supports the
"prefix" install. The only thing that nees special treatment is the
removal of files that should not be owned by the package (scollkeepers
content-lists for example) - But I did neither of the things I would
consider a requirement to the specs:
* a "standard" name
* a decent description
* correct requirements, build-requires
* correct license
* split the devel-parts into a seperate package

Post by Greg M. Kurtzer
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+),

Not sure what you mean with upstream names. The name of the tarball?

Post by Greg M. Kurtzer
and then compatibility libs or the non-default package versions
having the versioned nomenclature (eg. gtk1). I know this isn't realistic, so
gtk+=gtk2, glib=glib2, etc...).

Basically it doesn't matter what name we choose for the package. It is
only important that the packages that make up the gnome-desktop and
"fifth-toe" packages have names they can check for using a
requires-statement.

Post by Greg M. Kurtzer
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.

How this is organized doesn't really matter... Such an abstraction layer
will help build-tools, but the specs have to be generated when the
tarball of the package is created. Relying on such a build tool to
generate/update the dependancy information is not what we should
envision. It could be an intermediate solution, but nevertheless the
spec file should be self-contained. (you must be able to run
"rpmbuild -ba <specfile>" without using the build-tool first)

Post by Greg M. Kurtzer
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?

Well, my point is not that it is difficutl to set those defines, but
that it is difficult to maintain these. If that build tool doesn't
ignore the system's rpm-configuration the macros like %configure or
%make will work. You can even define "have_suse" or something. But the
problem is that when we do the "magic" in the specfile itself, it /will/
break sooner or later (and even worse: it will be harder to fix - you
risk breaking the support for the working distros when you modify the
spec). Maybe the main-distros and the popular packages won't be affected
- but what about the other ones?

ciao
Christian

[Luis Villa]

Post by Christian Lohmaier
Distros will build their own packages anyway.

Agreed.

To be very clear here (partially in response to Greg's email)- my goal
here, and what I think should be this group's goal, is *not* to
produce spec files distros or even necessarily end-users can use[1].
My goal (and again, I think what should be this group's goal) is to
produce packages of gnome's stable and unstable[2] releases that the
gnome project can distribute to testers and users. Spec files (of
whatever sort) are only a means to that end, so 'clean' doesn't matter
as long as the packages work for the testers/users and the specs can
be maintained by volunteer humans. That's MNSHO anyway.

So... if someone has a different way to produce packages easily and
maintainably across distros that is different from James' solution,
speak up :)[3]

Luis

[1] though if that happens, great, but realistically most distros are
forced to rewrite things themselves anyway, for their own custom
autobuild setups
[2] particularly unstable, and ideally of CVS
[3]Ximian semi-provided such a solution, but it was too complicated
for us to use at the time- if anyone wants to look at that, for the
archives, the tool's home page is:
http://primates.ximian.com/~thunder/bb/
and the build buddy conf files for gnome cvs (outdated) are at:
http://cvs.gnome.org/viewcvs/bb-snapshot-confs/gnome2-snap/

[Christian Lohmaier]

Hi *,

Post by Luis Villa

Post by Christian Lohmaier
Distros will build their own packages anyway.

To be very clear here (partially in response to Greg's email)- my goal
here, and what I think should be this group's goal, is *not* to
produce spec files distros or even necessarily end-users can use[1].

Not sure what you mean with end-users. In my definition the end-user is
the person that installs and uses the package.
I think we should target these users.

The "end-users" that will make use of the gpp provided ones are not the
newbies. The newbies should stick with their distribution. The end-users
we should target are the curious ones, that want to try things out or
the ones that need to compile everything themselves.

Post by Luis Villa
My goal (and again, I think what should be this group's goal) is to
produce packages of gnome's stable and unstable[2] releases that the
gnome project can distribute to testers and users.

That would mean to create binary packages.. One reason more against the
distro-switch approach.

Post by Luis Villa
Spec files (of
whatever sort) are only a means to that end, so 'clean' doesn't matter
as long as the packages work for the testers/users and the specs can
be maintained by volunteer humans. That's MNSHO anyway.
So... if someone has a different way to produce packages easily and
maintainably across distros that is different from James' solution,
speak up :)[3]

Well, I thought I did...
Basically it is just a matter what you require from the builder.
If you can make him to configure the rpm to use a certain set of macros
and don't worry about the split of packages (e.g. you'll insatll all the
files a "make install" would do without differentiating between "main"
package and "devel" package) all you have to do is decide where to put
the files I mentioned in my other post (mime, desktop, pkgconfig,..)

Then the spec file basically is reduced to
%configure
%make
%makeinstall
%find_lang

If you're only up to a system where the files are "indexed" by rpm
there's no problem at all, no need to fuzz with distro-specific things
at all.
But still the points I mentioned need to be put down. (where to put the
special files, what macros should be allowed, ...)

ciao
Christian

[James Ogley]

Post by Luis Villa
collaborate with James on a cross-distro spec file for some of the
basic stuff in jhbuild- maybe gucharmap and the core dependencies?

Here's a patch against gucharmap HEAD to add this facility

[Gary Ekker]

Post by James Ogley
Here's a patch against gucharmap HEAD to add this facility
--

Thanks for the efforts here. I would like to be involved as much as time
permits. Anything to get CVS more testing will be great.

Cheers.

-Gary

Post by James Ogley
pièce jointe
différences entre
fichiers
(gucharmap-gpp.patch)
diff -ruN gucharmap.orig/gucharmap.spec.in gucharmap/gucharmap.spec.in
--- gucharmap.orig/gucharmap.spec.in 2003-05-04 00:15:38.000000000
+0100
+++ gucharmap/gucharmap.spec.in 2005-06-15 06:58:16.000000000 +0100
@@ -1,5 +1,23 @@
# DarContact: Noah Levitt <nlevitt аt columbia.edu>
+%{?_with_suse:%define suse 1}
+%{!?_with_suse:%define suse 0}
+%if %{suse}
+%define prefix /opt/gnome
+%define sysconfdir /etc%{prefix}
+%define bindir %{prefix}/bin
+%define datadir %{prefix}/share
+%define libdir %{prefix}/lib

I think you'll need:
%define libdir %{prefix}/%{_lib} for bi-arch packages.

I think we need to include packages for x86 and x86_64 don't we?

Hopefully we'll get this problem resolved soon, and move GNOME to /usr/
rather than /opt/gnome although it won't happen in the next 6 months,
and even when we do, we'll still need to support this for a while.

Post by James Ogley
+%define includedir %{prefix}/include
+%else
+%define prefix %{_prefix}
+%define sysconfdir %{_sysconfdir}
+%define bindir %{_bindir}
+%define datadir %{_datadir}
+%define libdir %{_libdir}
+%define includedir %{_includedir}
+%endif
+
Summary: A featureful Unicode character map.
Name: gucharmap
@@ -13,7 +31,7 @@
http://ftp.gnome.org/pub/gnome/sources/gucharmap/0.6/%{name}-%{version}.tar.bz2
BuildRoot: %{_tmppath}/root-%{name}-%{version}
-Prefix: %{_prefix}
+Prefix: %{prefix}
%description
gucharmap is a featureful Unicode character map and font viewer.
@@ -31,7 +49,7 @@
%setup
%build
-%configure
+./configure --prefix=%prefix --sysconfdir=%sysconfdir
%{__make} %{?_smp_mflags}
%install
@@ -54,21 +72,24 @@
%defattr(-, root, root, 0755)
%doc ChangeLog COPYING* README TODO
%config %{_sysconfdir}/gucharmap/
-%{_bindir}/*
-%{_libdir}/*.so.*
-%{_libdir}/gucharmap/immodules/im-gucharmap.so
-%{_datadir}/pixmaps/*
-%{_datadir}/applications/*
+%{bindir}/*
+%{libdir}/*.so.*
+%{libdir}/gucharmap/immodules/im-gucharmap.so
+%{datadir}/pixmaps/*
+%{datadir}/applications/*
%files devel
%defattr(-, root, root, 0755)
-%{_libdir}/*.a
-%{_libdir}/*.so
-%{_libdir}/pkgconfig/*
-%{_includedir}/%{name}/
-#exclude %{_libdir}/*.la
+%{libdir}/*.a
+%{libdir}/*.so
+%{libdir}/pkgconfig/*
+%{includedir}/%{name}/
+#exclude %{libdir}/*.la
%changelog
+- Add GPP rpm-fu allowing --with suse to be specified.
+
- Updated to release 0.6.0.