[RFC] SPEC, RPM and SRPMS files for gnome 2.0 Alpha release

[Chris Chabot <chabotc reviewboard com>]

 I have commit this weekend on rewriting the .spec files for the gnome 
2.0 alpha release packages. This to allow better beta testing of the 
gnome 2.0 alpha platform, and to break the impase on this situation.

I do not agree with the current RPM packages on ftp.gnome.org, and as i 
was tought in the days when kernel 2.0 was a very hot new item:  Don't 
talk, code! Thus..



Why Rewrite the SPEC files?
----------------------------------------

o The current packages on ftp.gnome.org are, in my opinion, very 
dangerous. They do not use the base names that redhat 7.2 uses (the 
gconf2 style naming convention), and since they break this naming 
convention, installing them is likely to destroy a users gnome 1.4 
desktop. (even with users with mderate knowledge of rpm's and gnome 
structures)

o The current packages on ftp.gnome.org also do not have dependencies in 
them, obsolete's, or required's. Thus very easely allowing for a very 
broken system.

o They contain several severe errors, such as broken schema installs, 
broken %post run scripts, etc.

The above points lead me to believe, the current RPM's on the gnome.org 
server are useless for their intented purpose: Allowing users to alpha 
test the gnome 2.0 platform, to provide us with usefull information, 
user experiances and bugzilla entries.



What makes these spec files any better?
----------------------------------------

I have tried to make the spec files as clean as posible. All vendor 
specific information etc has been removed from them, consitent 
configure, make and make install rules, same identation scheme on all 
files, find-lang macro's on the right places.. basicly all the 
feel-good-stuff a spec file needs ;-)

I have rebuild all the packages several times on different hosts, using 
combinations of versions of gettext and autoconf, and they all seem to 
work well. I have installed the resulting packages on about 4 machines, 
and all the basic gnome 2 stuff runs well. (I have also included 
parallel build flags for all packages that support this, and tested this 
on a 2 and 4-way box for each package).

Last, they are very consitent, and maintanable. Instead of the half 
tool-generated, half patchy solution that is currently on ftp.gnome.org.



Remaining issues
----------------------------------------

As has been discussed on the desktop-devel list, the gnome2 applications 
packages break a gnome 1.4 setup (gnome utilities, games, etc). Various 
ways of fixing this in the future have been discussed, but as far as i 
am aware, no solution exists yet for the public.

However the new packages allow all the base libraries to be installed 
without breaking any existing gnome setups, and the userland 
applications can always be installed with "rpm -ivh --force gnome-utils* 
gnome-games* control-center*", this way you would have both the 1.4 and 
2.0 version binaries on your system, and the non ported gnome 2 
applications would still exist on your system, and function. Also since 
a few applications do have gnome2 style names (such as gnome-panel-2, 
gedit2, etc), these applications support dual-running of gnome 1.4 / 2.0.

So we would still have breakage, but very minor comparable to the 
current worst-case scenario.




What to do with these spec files?
----------------------------------------

I believe we would all be a lot better of, if we can put these (S)RPM on 
the ftp.gnome.org site instead of the current one. That fixes the 
imidiate problem of the risk that users can either not test the alpha 
release, or break there desktop trying to do so. Ofcource, i would 
strongly prefer if everyone could first give some ey-ball time to these 
packages, and spec files, before we unleash them onto the world.



... The Future
----------------------------------------

In the future, there are various paths we can take towards a 'workable' 
solution:

1) As we did currently, we can wait for someone to get an "itch", and 
fix everything up. However i don't think this is proper release 
engineering. And since we would like a lot of eyeballs on gnome 2.0, it 
would make sence to make it as safe and easy as posible for users to 
help out.

2) We can maintain the spec files seperatly from the sources, and a 
package team would update these files on each release, and build 
packages for a (days after the release) binary release. This is already 
a lot better then scenario 1. However in this scenario, i would 
_strongly_ advice to remove the old (broken, old and non relevant) .spec 
files from the current packages, to avoid confusion, breakage, and a 
general bad impression when a user tries to do a rpm -ta PACKAGE. Either 
have a working .spec file, or have non. There is no reason to bother the 
user with legacy code

3) We can import the .spec files into the CVS repository of each library 
/ application. Preferable convert them to .spec.in files, and have them 
generated with the correct version on each release preperation. This 
option has my personal preference, since RPM is the most used packaging 
platform, and it allows users to download a new release _when it is 
release_, and do a rpm -ta PACKAGE minutes after the release...

(a seperate discussion around this exists, if when we do this, we should 
put the .spec file in the root of the package, or in a ./packages dir of 
the package, allowing for .deb etc files to be put in a consitent place)

4) We abandon binary packaging completely, and leave it up to the 
distibuters. (not my prefered scenario)




Which ever solution we choose, i do believe the current scenario is less 
then desiriable. Also there seems to be a lot of different opinions on 
how to write a spec file, What a good spec file 'a makes, and if we 
should do it at all. Also a lot of nit-pick discussions exist on what 
kind of bz or gz support we should use in the packages, naming 
conventions, etc.. The big problem with this is that people tend to 
argue more then do actual work.. This is a recipie for disasterous 
release engineering.


So what would be my prefered scenario?
----------------------------------------

Preferably i would like to see a release team, that coordinates with the 
packaging team before the release date, to make sure that every package 
builds out of the box (else fix it or don't include it in the release). 
And them makes SRPMS/RPMS for the release.

Where to maintain the spec files? I would say in the CVS of each 
package.. This way people can also make .rpm's of CVS snapshots.. it 
also allows the maintainer to make changes as he see's fit (would he 
desire to do so).

Where to report bugs? I think the easiest way would be to make a 
"Packaging" component to every gnome2 application, and assign something 
like gnome-packaging-maintainers gnome org to it. This way package 
maintainers who dont want to / can not / think its estaticly non 
pleasing to maintain .spec files, can sign any bugs in bugzilla over to 
the gnome packaging team. allowing for consitent and good future 
maintanance.

What to do with package requirements? (cross-vendor rpm's) If we include 
named requirements for the gnome release (ie, for all gnome library 
dependencies), and allow rpm to generate the .so requirements for the 
other libraries (such as freetype, x, etc), the SRPMS should work on 
most RPM based platforms.. This way we can have a 'Vanilla GNOME' 
platform, and leave the platform specific fancy dressup to the 
distributers (ximian, redhat, mandrake, suse, etc).


Where can i get these RPMS / SRPMS / SPECS
----------------------------------------

I have put the files on http://mailman.chabotc.com/pre-gnome2
ofcource this being my personal server, i would prefer it if that 
location wouldnt be anounced on slashdot and news.gnome.org. Else my 
bandwidthbill might get a bit crazy ;-)

(ps, the RPM's were build on a stock redhat 7.2 box + erate + autoconf 
2.52-6 as was adviced in the gnome 2.0 alpha release anouncement).

(pps, if that libtoolize thingy is a problem, why not just define 
__libtoolize to /bin/true? as far as i know this 'solves' the problems 
while using the rpm build in macro's for configure / make / makeinstall)

Last note, this anouncement / RFC / Rewrite isnt intended to insult the 
current packagers. More is it inteded to have a working gnome 2.0 alpha 
platform for redhat 7.2 users, and to hopefully spark off a discussion 
that will properly define a good release engineering guidelines and 
methods for RPM platforms.

   -- Chris Chabot