2007/3/23, Kevin Kofler <kevin.kofler@chello.at >:

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list