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



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






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]