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

[Gregory Leblanc <gleblanc linuxweasel com>]

<disclaimer> Please try to forgive me if I sound a bit defensive, but
you're slamming my work.  I try not to take it personally, but it's hard
to begin with, compounded by the fact that you decided to go do your own
thing, rather than help out with the packages that I made. </disclaimer>

<note>I let the message sit for a full day before sitting down to write
my reply.  I let the reply sit for a while, then re-read it, then had
somebody else read it, to make sure that I wasn't completely on crack. 
Please don't just fire off a reply, think about it for a while. 
Thanks.  </note>

On Sun, 2002-01-20 at 12:10, Chris Chabot wrote:
> 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..

Well, they are broken, I think I said this when I sent out a message
about them.  They're a first go at getting everything to compile, not
something that's ready for use.  That said, I'm glad you've found
something to work on.

> 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)

They're not intended for users.  It's not like there's a list of
packages that need to get renamed, one has to go through and look at all
of the packages to find the duplicates.  

> 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.

Not that easily, actually.  They don't have explicit, manually
determined dependancies, but they do have all of the automatically
generated dependancies, which is actually sufficient 90% of the time.

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

WHERE?  Every package installed properly for me, and ran the schema
installs without error.

> 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.

Uh, their INTENDED purpose was to give people who wanted to work on RPM
packages for GNOME 2 a place to start.  Once they WORK, then the above
purpose will be correct.  I guess I need to make that more abundantly
clear...  There was no announcement sent anywhere other than the
packaging list, where I assumed only clueful people would be
watching/attempting to use the RPMs.

> 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 ;-)

Cool...  For what it's worth, it's impossible to remove all vendor
specific information, though I'm sure you got as much as is possible
(and hopefully not any more than that.  :-))

> 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.

Nothing there is generated by tools, where'd you get that idea?  I don't
see why they're "patchy" or unmaintainable (by implication) either. 
Plus, I know mine are at least 80% consistent, the rest are simply
waiting on someone having time to clean them up.


> 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.

There are actually two options for fixing desktop packages dual
install.  'rpm -ivh --force' is NEVER EVER EVER EVER the right solution
to get parallel installed packages, no matter what.  NEVER.  Ahem,
sorry, but reinstall systems for people when they do that stuff, it's
horribly annoying.

The first solution is to install things into a different prefix.  This
is OK for people who use GDM, as it shouldn't be too hard to add another
session to GDM, so that people can either log in to GNOME, or
GNOME-pre2.  

The second solution which should solve quite a few of the parallel
install problems is to pass something like --program-prefix=BORK to all
of the configure scripts, so that instead of /usr/bin/panel, we end up
with /usr/bin/BORKpanel.  I'm not sure how much other overlap we'd have
here, but it might be enough to make this solution workable.

> 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.

I'd have done this solution wholesale, without any qualms what-so-ever,
if you'd started with the spec files that are there.  Since you didn't,
they'll need serious review before I personally put them up there, and
before I do that, I'm likely to work on fixing my own packages.

I'll work with mine because I know their status, and I've got a pretty
decent idea what needs to be changed, and I've already got all of them
in-place and ready to be used on my development systems.  It's simply
more efficient for me to work that way.

Hopefully, other people will have time to look at them, but I don't
right at the moment.

[snip]
> 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.

I'm on the release team, for just this purpose.  Since I hadn't had
anybody step forward and volunteer to help, I did most of this myself. 
There weren't that many packages which didn't build, and several build
problems got caught before the release actually went out.

I need some suggestions on how to parallelize this task better.

> 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.

We can certainly manage the gnome-packaging-maint gnome org alias, but
I'm not sure on the rest of it.  I'll get back to this in a little
while, I've just asked my local QA Guru.

Ah, back from talking to QA guy.  Sounds like the solution that Ximian
is using is to create a product called 'Ximian Packages', and as a list
of components for this package is every module that's packaged.  This
risks people not knowing where to file bugs, but makes things pretty
easy for us to keep track of.

The other option is to create a 'packaging' component for all of the
modules in bugzilla, and assign ourselves as the owner of that
component. This can get hard to track, since they're spread out all over
creation.  If we're very careful to name them all the same thing, this
becomes slightly less of a problem, but doesn't quite get eliminated.  

Ack, here I go asking for feedback again in the middle of your request
for comments.  :-)

> 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).

Vanilla is a flavor.  What you're talking about here is an unflavored
distribution of GNOME, which I've been calling Plain GNOME.  Vanilla !=
plain, unless you're a really strange chef.  :-)

> 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).

Erk, so they're not gonna work on my systems, I'll have to rebuild if I
want to test.  :-(

> (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)

Well, mostly because I'd rather avoid any future stupid idiotic things
added to RPM, as Jeff has a tendancy to do.  I like stuff that actually
works, consistently, reliably, and without having to resort to 'stupid
tricks'.  That's my rationale for not using %configure.  %makeinstall is
probably ok (at least, I can't remember any problems with it).  There is
no built in, portable %make macro.

> 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.

Heh, where the hell were you last time I tried to start this?  :-) 
Thanks for putting up with my drivel, hopefully the words aren't too
biting.  Yes, I put off this reply for more than a 
-- 
Portland, Oregon, USA.