kdelibs 3/4 conflicts, plan

[Rex Dieter]

Appended is a snippet from a conversation this morning on #kde4-devel 
... thiago asked me to post it for wider consumption.

Of particular interest to kde-packagers is stuff before
===
after, kde-core-devel folks. :)  Enjoy.

-- Rex


[08:01] <rdieter> still seeing lots of kdelibs(3)/kdelibs(4) parallel 
install conflicts: 
http://www.math.unl.edu/~rdieter1/kde/kdelibs-3.5.7_3.92.0-conflicts.txt 
  suggestions?
[08:02] <rdieter> (icons mostly, from the look of it)
[08:08] <thiago> rdieter: the first 5 are developer tools and shouldn't 
be in kdelibs, but kdelibs-devel
[08:08] <rdieter> thiago: thanks! that's 5 down... :)
[08:08] <thiago> rdieter: the kate ones... technically you can't have 
two applications called "kate" installed
[08:08] <thiago> but that's libkate actually, not kate itself
[08:09] <thiago> the syntax highlighting files I'd place in a .noarch 
file that would be common to *both* kates
[08:09] <thiago> provided the syntax of the files didn't change. Ask the 
Kate guys.
[08:11] <thiago> the kdewidget PNGs are also development files.
[08:13] <thiago> about the icons... I bet those have to be made Oxygen 
icons too
[08:13] <thiago> ksgmltools -> development
[08:15] <thiago> all files that are placed in config/ are supposed to be 
upgrades and must be readable by the older version too
[08:15] <thiago> so those are not conflicts
[08:16] <thiago> I had no idea we had emoticons and I don't see any 
index file in the list
[08:16] <thiago> hopefully nothing changed in their structure, so they'd 
go to a separate, upgradable package
[08:18] <rdieter> thiago: thanks a bunch...
[08:19] <thiago> that seems to be all that you can do from the 
packager's point of view
===
[08:19] <thiago> the rest would require changes in KDE
[08:19] <thiago> all of the kstyle stuff: I'd move into a separate 
directory, kde4-dependent, since that is arch-dependent
[08:21] <thiago> kdeprint: looks like all of those are shared, but I 
can't confirm nor can I guarantee that it will remain so. That is mostly 
like that now because kdeprint has seen not much love in the KDE 4 
development cycle.
[08:22] <chouimat> morning
[08:22] <thiago> we have some private files of a library (katepart, 
khtml). I'd move those to a directory containing the library's soversion.
[08:24] <thiago> if it's an unversioned library (like katepart: 
lib/kde4/katepart.so), files should be inside share/kde4 too
[08:27] <thiago> rdieter: so, s/kdeui/kdeui5/, s/kdeprint/kdeprint5/, 
s/khtml/khtml5/, s,apps/(katepart|kcm_componentchooser),kde4/apps/\1,
[08:27] <thiago> rdieter: that trims down the list to 5 items: 
kconf_update, kjava and kssl
[08:27] <thiago> wait, kssl is a shared file
[08:27] <thiago> so, 4 conflicting items
[08:27] <thiago> rdieter: can you do me a favour now? Post all of this 
to kde-core-devel? :-)
[08:28] <rdieter> thiago: can do.
[08:30] <thiago> rdieter: the only thing that would be difficult to 
implement is the share/kde4/apps thing, since it would require a 
KStandardDirs change. The rest is simple, proper management of ones 
resources
[08:35] <thiago> rdieter: the basic idea is to say, "if you maintain 
binary compatibility with KDE 3 (or KDE 5), you can use an unversioned 
name; if you can't have both installed at the same time (say, an 
application-specific file), you can have the same name"
[08:35] <thiago> rdieter: "otherwise, you must add a version to your 
directory, either your soversion, or KDE's or 'kde4'"