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

[Evandro Fernandes Giovanini <evandrofg ig com br>]

Em Ter, 2002-01-22 ās 01:51, Chris Chabot escreveu:
> 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.

These packages are in the pre-gnome2 directory, which has a README file
(pub/GNOME/pre-gnome2/README). The release announcement for GNOME 2.0
Desktop Alpha is very clear about the status of these packages.

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

In the .spec.in files included with the official tarballs I think a
<module> package should be named <module>, not <module>2. To provide
compatibility with Red Hat, however, you could use 'if'. You'd have:

Name: %{nam}

If there's a file /etc/redhat-release, then nam = module2. Otherwise,
nam = module. 

What do you think?

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

Then why rename the library packages at all, if you're going to fsck up
things later?

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

1) the packages won't break the system if you don't tell them to (by
using --force);

2) the desktop packages conflict with gnome 1.x versions, so if you're
going to split them, split them to libraries/ and desktop/.

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

It does allow for an apt-get repository, at least if you're using
Conectiva's port of APT. The APT database contains information on what
the packages provide and what they require. 

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

You should write down everything that is broken and send patches to the
spec files to fix them. This is how you would go about other things too,
and in the end your work will be merged.

To create a patch:

cp file.spec file.spec.orig (where file.spec is the gnome.org spec file)

make changes to file.spec and run:

diff -uNr file.spec.orig file.spec > file.patch

Now send file.patch and a description of it to the list.

> 
> >[..] 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 ?! ;-)
> 

You may or may not like Mandrake's (Debian, actually) naming policies, I
respect that. But please read
http://www.linux-mandrake.com/howtos/mdk-rpm/advanced.html#LIB-POLICY
before making a decision about them.

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

There really is only one solution to this problem: tell people this is a
_horrible_ 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 think things would move faster if you sent the patches.

--
Evandro