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

[Chris Chabot <chabotc reviewboard com>]

Gregory Leblanc wrote:

> <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>
Thats why i finished my rather lengthy email with a disclaimer of my 
own. My intent is not to upset you, just to cause a bit of discussion 
and hopefully when all the whirlwinds die down, a better solution for 
all. Also, dont wurry, i do not upset so easely ;-)

> [..] 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.
My personal feelings on the topic are a bit different. Since 
ftp.gnome.org is a public server, there is a awefully good likelyhood on 
a unsuspecting user (note: not gnome hacker, more on this distinction 
and its implications later) comes to that server, remebers reading about 
gnome 2, and that gnome 2 requires help with testing... ergo, he 
downloads the packages... (more on why this could be bad below)

> [..] 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.
First off, when you put them on a public server (without a big 
"DISCLAIMER_READ_ME_NOW" as a posible warning sign), can solicite people 
to try them out... not intended, i know, but it is bound to happen.

As far as a list of package names goes.. thats easy to nail down, just 
follow these rules:

if it is a part of bonobo or formaly gnome-libs, then the name has 
changed to "lib...", so no package conflict exists here.
if it is one out of the folowing, add a '2' to the end of the package name:
- gconf
- glib
- gnome-vfs
- gtk
- libglade
- eel
- ORBit
- gedit
- libxml
- librsvg

Procman and gnome-common didnt previously exist on redhat platforms, so 
are 'safe' anyways there.

for any other case, the package _will_ conflict with the gnome 1.4 
version (gnome-core, -applets, -utils, -games, bug-buddy, nautilus, 
nautilus-mozilla).

Installing the later with "rpm -ivh --force" will preserve a mostly 
working system (since then it does not remove the old binaries, and 
either the tool isnt ported yet, or it is renamed in most cases. In the 
cases where that is not the case? Well you got yourself a gnome2 system 
<grin>).

I would actualy propose to include all later named conflicting packages 
in a 'optional' directory, and / or atleast label as 'will break your 
system!! do not use unless your insane or sure what you are doing!!"


> [..] 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.
This does, however have a few downsides. First of all, it doesnt allow 
for a apt-get repository (it needs the actual package names), and 
secondly, it makes it a lot harder on the user to figure out what to 
install to get a working situation.

> > 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.
I believe this happened in gnome-core (mailcheck, tasklist and pager 
schema's dont exist in gnome-core 1.5.4). So if it installed without 
error, we truely have a weird bug on our hands ;-)


> [..] 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.
So reationale @ the top of this email. Once you release rpm's into the 
world (public primary server?), then there's a chance less cluefull 
people might get exposed to it ;-)

> [..] 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.  :-))
Heh, yea i tried to stop in time ;-) I did notice quite a few of the 
dificulties with cross-rpm platforming (mandrake weird library naming 
(in my perspective), and wtf is up with the %configure25 macro ?! ;-)

Anyways, i tested all my .specs on a redhat 7.1 and 7.1 box, plus on a 
current rawhide box.
(in the latest case, 4 packages failed to build, but this is due to a 
heavely changed ABI/API in gcc 3.1)

> [..] 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.
In quite a few spec files i noticed they were made by 
"builder localhost localdomain". i gues i jumped to conclusions there ;-)

As far as cleaning up goes... i also had the feeling they needed to be 
cleaned (obviously), and i actualy merged the good bits from your .spec 
files, and used them as a bases for a few other packages..

However, no requires, no buildrequires, hardly any descriptions, 
summaries that stated "window manager thingies" <grin>... ok the last 
example i wasnt able to improve on ;-)

Other then that, i am not gonna tell you your work is bad, all your 
blood, sweat and tears you spend on them deserve better. However, i 
would like to invite you to take a look at the set i produced, and 
consider if they might make a good foundation to continue on.

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

Heh, i know that for you, from the perspective of a person who has 
intimate knowledge of the working of binary package libraries on 
platforms, this comes as a complete shock... But most beginning users 
_do not know this is a bad thing_ !

Think back to when you were first on a unix style console, and you tried 
to compile your very first program your self... now this probably 
failed.. missing params and some other voodoo magic you couldnt figure 
out... This leads to frustration and desperation, and then later to 
education ;-)

Now imagine if in those first failures, you would be able to to:
./configure --i-realy-realy-want-you-to-work

and it would magicly work!!


Now, this is the experiance of any beginning linux user who uses --force 
on a redhat system. They have no clue what it does,  however this 
'voodoo magic' did make it work!

It is only later down the road that they notice a ./configure failed 
cause they had 2 versions installed of a package.. or when they try to 
upgrade rpm's, and all hell breaks loose.

Mostly, they just re-install their systems, and use the same old 
behaviour. Hey this is how you do it in windows to right? Make it work, 
till it stops working for some magical reason, and then reinstall ;-)

I know this is not how it is supposed to be, however, if we can prevent 
a part of this to happen, the world will be a much happier place for 
beginning gnome and/or linux users.

> > [..] 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.
Heh, this is funny from my perspective.. I emailed you a few times 
during your building of them, asking if i could get your so-far work, 
and if i could contribute in any manner to them. I took your deafening 
silence as a 'no' ;-)

> > 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.
I can respect this from a coders perspective. It's a lot easier to be 
'in to' your own work.

I hope that you might find an spare hour somewhere in the near future, 
and be able to take a look at them. If they are shit, you'll know soon 
enough... If they are not, why not consider building them and running it 
quickly? If they run well, why not consider merging our efforts?

I showed your work the respect it deserves, by building and installing 
them (knowingly breaking my existing gnome setup in the process), and 
trying them out. (Ofcource, my end conclusion being, that this needed to 
work better, and thus my rewrite & lengthy email began)

Hopefully you will be able to find the time to show my efforts the same 
intrest.

> > Hopefully, other people will have time to look at them, but I don't
> > right at the moment.
Actualy, a few people already have shed some eyeball light over them, 
and so far comments have been all good. Have recieved a few small 
corrections, and incorperated them already.

> [..] 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.
Well i think that if we can get our efforts merged, i'll be more then 
willing to help out with future releases.

Parralizing would probaly involve a ftp server, or cvs. And deviding up 
the need-to-be-done packages between the available people.

Since building spec files is tedious, and extremely boring work, i think 
the benifits for general quality will be great if the work is spread 
amongst several people.

> [..] 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.
I think that alias / list would be a good thing, once we have identified 
a few people who are willing to help maintain the spec files, and do 
some QA on them.

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

I think the downside of using a 'Packaging' component would be that it 
might be harder for people to find. But then again, if they are not 
gonna find that, whats the likelyhood of selecting the right 
subcomponent ;-)

With that in mind, i'd say, create a Packaging project entry, and add 
packages as components to it.

That way, a bug filed to the package, and not the "packaging project" 
can easely be re-assigned to us, and we can triage / re-assign to proper 
sub-components as needed.

if we can settle (read: after ;-) this little dispute, i'd be happy to 
have me added to the 'responcible' list for that project.

> [..] 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.  :-)
heh, dont even get me started on my cooking skillz! Just be glad you 
dont live near here so you dont have to find out for your self ;-)

Anyways, vanilla is often the word used to describe a 'plain' linux 
kernel. Since ive been using that description of a 'plain' version of a 
linux component for so long, i gues it got stuck.. anyways, ill try to 
update my dictionary ;-)

> [..] Erk, so they're not gonna work on my systems, I'll have to rebuild if I
> want to test.  :-(
Whats the part that boged you? Redhat 7.2 or autoconf 2.52?
If you feel redhat 7.1 (or even .0) is a better place to build these 
packages, i can easely make a chroot envirioment with 7.1 in it, and 
build there.

Ps, for rebuilding ive set up a Dual P3 1Ghz server, 2 gigs of ram, and 
a dual channel scsi u160 software raid 0 (120megs a second read/write!) 
server. i find it makes testing and rebuilding a lot easier.

everytime i consider releasing the results onto the world, i first 
rebuild them on my workstation and laptop, to make sure they realy do work..


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

The thing for me was that i realy like the macro's.. they make the spec 
file a lot smaller, easier to read, and prevent typo's in the configure 
/ make install lines..

If a simple __libtoolize define is needed to have that work everywhere 
(platforms with different autoconf tools), then thats a sacrifise i 
would be willing to make.


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

Actualy, i was mailing you to ask if you needed help!! ;-)

Your drivel wasnt as bad as you make it sound at all. I was bracing for 
a lot worse ;-)  Anyways, i hope we can come to a good conclusion, and i 
realy hope you will find the time to take a look @ the spec files, and 
posibly building them. There's a lot of effort that went into them, and 
they are of prety decent quality. If we then decided to merge, or we 
flame war on.. or i chicken out and take my self elsewhere, or i decided 
to try to change your spec files... who knows ;-)

Thanks for the patient reply and feedback Gregory.

   -- Chris Chabot

ps, you never did finish that sentence... "for more then a"... ?