Hello, > 1. Do we need the kde-i18n- ports?
As these ports are from the kde3 suite, I would say they are as relevant as any KDE 3 port. > 2. Do we need the KDE 3 ports? > > KDE 3 is now obsolete and no longer supported by KDE. MacPorts says that > KDE 3 and KDE 4 ports "conflict". I think that means you cannot install a > mix > of KDE 3 and KDE 4 ports. On Linux you still(?) can. They are kept > separate > by using different working directories, library names, etc. Some KDE 3 > apps > never got ported to KDE4/Qt4 and people come looking for them sometimes. > The usual reply on KDE lists is, "How about helping by porting it to KDE > 4?". KDE 3 is indeed obsolete, and I don't know how much kde3 is still working in MacPorts. On the other hand, I don't know how much harm it does to keep it if some ports are still functional. Apparently, the following ports still depend on kde 3, apart from the standard kde suite (if I did not miss any). It tried to summarise their status too for what I could find. kcachegrind (also exists for kde4, but not in Macports yet) kmm_banking (obsolete in kde4 as already contained in kmymoney4) filelight (also existing in kde4 as kde4-filelight) kmymoney (also existing in kde4 as kmymoney4) qalculate-kde (not yet ported on kde4, but exists as a plugin for cantor, not available on kde4) klibido (not ported on kde4) taskjuggler (not ported on kde4) kile (also existing in kde4 as kde4-kile) slicker (obsolete on kde4 ?) koffice (appears rather obsolete, and there is a ticket in trac to provide calligra) konversation11 (also existing in kde4 as konversation) kchmviewer (appear to be ported on kde4, but not on Macports) It seems there is indeed not much left which uses kde 3, when looking at the status of most ports, though. > 3. Does MacPorts delete KDE users' data files when it uninstalls/re-installs? > > I suspect it does. See the section in the Wiki on "Installation > location". In > ~/Library/Preferences/KDE, we have share/apps, share/config and share/kde4. > > share/config has one file per app, called <appname>rc. This appears on Mac > in the <AppName>Preferences… menu item. It is right and proper to preserve > this across installations. > > share/apps has one directory per app, called <appname>. KDE applications > use this to store data the user has created when using the app. It should > be > preserved across installations. For example, if you are using kdegames4's > Palapeli jigsaw-puzzle app, that directory contains puzzles you have > created > from your own pictures, plus the current state of all puzzles you are > currently > solving. You do not want "mum" to come and tidy them up … :-) I don't think Macports deletes these files, at least most of them. Macports only uninstalls the files copied during installation, not the files created at runtime by the application. If you run "port contents <appname>", the <appname>rc file will not show up, neither the files in ~/Library/KDE. > 4. Many KDE apps come with user manuals: should MacPorts install them by > default? > > If no, I will add a recommendation to the Wiki to use the +docs variant. > If yes, > is there perhaps some more efficient way for Macports to provide them? Adding a mention of the +docs variant in the Wiki would anyway be an excellent idea. It is missed by many users, as it is defined in the portgroup, and thus does not appear when running "port info portname" or "port variant portname". Cheers, Nicolas _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
