Experimental KDE 3.80.3 specfiles

[Kevin Kofler]

Chitlesh GOORAH <chitlesh <at> fedoraproject.org> writes:
> I don't know in details I didnt have time to have a look at the codes.
> And since your patch was failing, ive just removed it during the
> build.

It's not really practical to try to merge my patch as a patch. The only really 
practical solution is to redo it:
1. make a copy of the source directory
2. run KFileReplace on it with the kde4home.kfr file in 
http://www.tigen.org/kevin.kofler/pcprogs/kde-3.80.3-2-specs.tar.bz2
3. scan the changes for false positives and revert these.
4. create a diff.
One way to do step 3 is to take a diff, then open both the original and patched 
directory in Krusader (hooray for 2 panes), and looking at the diff, copy the 
original file back to the patched directory if all changes in a file are bad, 
otherwise use Kompare (select the original file on the left and the patched one 
on the right in Krusader and pick File/Compare by content from the Krusader 
menu, this fires up Kompare) to revert the bad changes only.
There's some manual work in step 3, but it's the highest amount of automation I 
could attain. Mechanically replacing things like .kde with .kde4 is not a safe 
change, I tuned the replacements to avoid false positives as much as it made 
sense, but there's several ones left I can't easily filter out automatically. 
Be warned that this also means some understanding of what the code is trying to 
do is required.

> The wallpaper willnot be accessible.
> I should dig into it later on to enable plasma.

As far as I understood, the situation is this:
* Kdesktop has been replaced with krunner.
* Kicker has been replaced with Plasma.
* The desktop functionality (icons, background) has been moved from kdesktop to 
Plasma.
* They replaced (or are replacing, I'm not sure of the exact status) kdesktop 
with krunner before replacing Kicker with Plasma in SVN.
And all this leads to the desktop functionality being temporarily missing.

> Kevin if you are working on updated specs, I'm ready to host them and
> their srpms.

Well, sorry, but I'm more likely to upload 3.80.3 packages with some backported 
bugfixes. I collected 2 of them already for bugs which annoyed me, if anyone 
knows a patch in SVN which fixes an annoying bug (NOT a global source change 
like Oxygen or shared-mime-info or an API/ABI change!), please give me the 
revision number. (Note that I don't take patches which are not in the upstream 
SVN unless you have a really good reason why I should (i.e. it's 
Fedora-specific or required for safe parallel-installability with KDE 3), 
please get your fixes upstream first!)

My plan is that the next version update for my packages will be when KDE 
releases the next official snapshot. AFAIK, this will be Alpha 1 around May 
1st.

Why? For one, I don't want to redo my parallel-installability patches all the 
time. (As you already noticed, and as explained in the first paragraph, simply 
updating/merging them isn't really feasible.) Updating them for each official 
snapshot is already enough work. And secondly, I'm using these packages to 
develop applications (well, currently one application) against them. I need 
packages with a well-defined API which doesn't change all the time, so I can 
specify that my CVS HEAD compiles against KDE 3.80.3, not that it may or may 
not compile against the current HEAD of the KDE SVN trunk depending on the 
phase of the moon. ;-) See, this is where our needs differ: I'm a developer, 
and I need the packages as a development platform. Thus I need full 
parallel-installability with KDE 3 (in particular seamless integration in a KDE 
3 session, I'm not going to try to develop in a KDE 4 session, especially not 
with something like your script which breaks running all KDE 3 apps in the 
session). And frankly, I couldn't care less about full KDE 4 sessions at this 
point. I'm most likely not going to run the KDE 4 workspace before it becomes 
the default KDE workspace (replacing KDE 3). (The way the KDE and Fedora 
timelines align, that might be as soon as Fedora 8. It will require a rock 
solid compat-kdelibs3 though.) I also don't really have a use for modules like 
kdenetwork4, kdepim4, kdegraphics4 etc. at the moment, except possibly for the 
packages which are new in KDE 4 (like Okular). (I'm not opposed to someone 
packaging them though, the framework is there with my base packages.) On the 
other hand, you want the latest and greatest snapshot in order to show users 
what's the latest from KDE development. This is an entirely different use case. 
For example, a script like your startup script works for you because you want 
to show only KDE 4 apps anyway, not KDE 3 ones.

        Kevin Kofler