[RFC] SPEC, RPM and SRPMS files for gnome 2.0 Alpha release
- From: Chris Chabot <chabotc reviewboard com>
- To: desktop-devel-list gnome org, gnome-packaging-list gnome org
- Subject: [RFC] SPEC, RPM and SRPMS files for gnome 2.0 Alpha release
- Date: Sun, 20 Jan 2002 21:10:13 +0100
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]