First, the layout of the repositories. The most basic thing is I think we need separate KDE3 and KDE4 backports repositories. Currently the backports repository is a mix of KDE 3 and KDE 4 software, and without hunting through the dependencies it is impossible to tell what is KDE 3 software and what is KDE 4 software. For people wanting to keep a clean KDE 4 system this a hassle, especially when there are KDE 4 alternatives available.
Agree on further removal/isolation of KDE3 packages from projects. If nothing else it makes it more obvious where a KDE4 alternative is missing.
I also think that the naming of the "playground" repository is misleading. KDE's playground has a specific meaning, which is not the same a the opensuse KDE playground repository. I think if we are using the same names as KDE, it should do the same thing, and if it does something different it should have a different name. Something like "experimental", "testing", or "unstable extras" would be better in my opinion.
What I would really like to see is clarified guidelines on what goes into Playground (or its renamed equivalent) vs Community/Backports (is is alpha? beta? "stable"?). Another big question I have is that what do you do when a package in Playground goes stable? How do you communicate to the users that the upgrade path is to change repositories? IMO what we have is a conflict between developer/packager requirements and user requirements. The developer/packager would like many projects, each containing only a few tightly related software so that maintenance is easy, lots of chances for branching, and there are not too many people trying to work on the same thing at once. The user wants as much software to be available from one repository as possible so there is less chance of adding conflicting repos, easier updates, etc. How do we reconcile these two conflicting requirements? Do we separate the idea of the repository and the build service project (i.e. multiple projects feeding into one repository), or do we create a new object that it is a set of related guaranteed-non-conflicting repositories and ask users to add/remove those instead? Or something else? This has been pretty much discussed before, especially in the context of the KDE repo layout, and the current situation just about works, so I for one don't want to disturb it.
Speaking of KDE repositories, in my opinion, opensuse could do a better job packaging software from KDE's own extragear repository. For instance the google akonadi resource was released as stable just a week after 4.3 was released, but was not actually packaged by openSUSE until after 4.4 was released over 6 months later. On the other hand things from kde-apps.org and kde-look.org get packaged almost immediately. Kchess, for example, was released on kde-apps.org 2 days ago and is already available from opensuse.
There are similar issues with playground. For instance openSUSE still does not have the mplayer or vlc phonon backends, despite the fact that they are packaged by other distributions and are supposed to be a in a pretty usable state and hosted by KDE, while marave, hosted by google and much newer, is available. Other, probably less stable playground software and third-party software is packaged as well.
This is indicative of the lack of a single to-be-packaged list for packagers. There is a horribly out-of-date and long list of packages on the wiki (http://en.opensuse.org/Package_Wishlist) that noone reads (and has a big notice not to use). There is openFATE, which is nice but is lacking in screening (both in tools and people to do it) and organization features (how can I get a list of all features that are requests for KDE-related packages?). There is also a strong sense that stuff from kde.org is the "KDE Team" responsibility and that stuff from kde-apps and kde-look is "community" responsibility. Maybe it should be that way, maybe it shouldn't, maybe its unintentional, but that's definitely the way the work is split right now. This is the reason for a lot of the discrepancies you see. There has long been talk of an automated dashboard that watches kde releases and kde-apps and has an overview of what packages need updating, but it doesn't exist yet. I don't remember whose pet project this was ... As a result of this situation packagers just package what they need, so for example I wanted to try out marave so I packaged it. As for vlc/mplayer that's a legal no-no on Novell servers. Eventually people just end up asking on the packman list and that's even worse, because then you end up compiled against only stable/old KDE, and you get silly incompatibility crashes :P An organized direction to packager efforts would cause the biggest improvement to the openSUSE KDE experience out of everything I can think of.
There is also an issue with missing or broken dependencies. For instance the main cantor backend, sage, is not available from openSUSE, making cantor pretty useless. Neither is R, another backend. Further, the only backend available (besides the built-in kalgebra one) is maxima, and you have to add another repository to use it. I'm not sure the best solution for that, but it is an issue. Ideally packages required or suggested by KDE software and that opensuse is legally allowed to distribute would be available in the main opensuse oss repository and/or the kde desktop/backports repository, but that may or may not be feasible.
This is a problem (not that I have a solution) with the way the opensuse repositories and teams are organized. Normally things like sage and R would fall under the purview of, for example, the Education or Science/Math guys. But suddenly the KDE team needs them packaged. So there is duplication of effort and confusion all round, with 20 different versions of the same package all in different repositories, packaged by different folk. Or it just ends up being missed out. Or users have to add 30 different repositories to get everything they need. None of these is ideal. This is a bigger problem than KDE, the duplication of effort on the OBS is huge. I wonder whether there should be a notice like "I see you are trying to build amarok. There are already 122 other home projects that build amarok. Please check if one of them already provides what you need". And the number of packages that are simply links (not even aggregates) of packages with no source changes at all ... but maybe this is all just a side effect of a healthy number of users.
With the release of the netbook reference version, I think that the release should be mirrored in the KDE repositories so openSUSE users can easily install it as their main system. Other future reference implementations would also be made available (or put in a single repository with meta packages that would pick out just the bits from a given reference implantation). This would also solve the request of having vanilla KDE packages available. The argument to this point was that it was infeasible, but if you are working with KDE to provide vanilla KDE packages that install on opensuse then I don't think it would be much extra work to just put those same packages in the repository (although I could be wrong).
Available from day 1: https://build.opensuse.org/project/show?project=KDE:Netbook And vanilla KDE packages are sort-of available, the -branding-upstream packages remove all of the SUSE artwork and some of the customisations. If you want more vanilla than that, well I don't know, why are you using distribution packages then?
I think that the KDE release one-click-installs (currently named KDE4-BASIS, KDE4-DEFAULT, KDE4-DEVEL, and KDE4-GAMES) should be renamed to match the new KDE branding. Namely, there should be a kde-platform ymp for just the libraries (so people can use KDE in a non-KDE DE), a kde-workspaces ymp that includes the desktop environment but no other software, a kde-sc-base and kde-sc-default corresponding to to the current kde4-basis and kde4-default, respectively, and then kde-devel. I don't think there is any need to have kde4 in the names anymore.
Currently the packages like kdeedu, kdeadmin, and kdegames do not do much beyond just installing the libkdeedu and libkdegames packages, which is fairly redundant. I think it would be better if these installed the software that is part of the respective KDE svn repositories. So, for example, installing kdeedu would install all of packages built from software in the kdeedu svn repository. This would also simplify the kde4-games ymp, it would just need to depend on the kdegames package and any other games not packaged with a KDE sc, instead of all the games individually.
There is confusion (at least in my mind) over what should be in 1) ymp one-click installs 2) patterns 3) meta/virtual packages Some guidelines and consistency across openSUSE teams on these would make life easier :)
As for non-packing issues:
I think we need a fix for the kdm configuration issue. There is already a kdm configuration tool, I think we should be allowed to use it (I'm not implying we are purposefully blocked from using, just that it cannot be used currently).
Yes, YaST /etc/sysconfig editor is not quite as intuitive, but the /etc/sysconfig way of configuring thing is well entrenched in SUSE. The only solutions are to hack the KDM configuration module to modify sysconfig (major change from upstream) or disable it (as is done now).
If you open the "network settings" module in KDE's system settings, it tells you that opensuse is not supported, then lists all the supported platforms (suse linux 9.1 is the most recent suse version supported). I think having support for opensuse in the KDE network settings module is important. I might be missing a package that provides support, but if there is such a package it should probably be a dependency.
Umm ... that works for me with NetworkManager-kde4, but maybe you are talking about traditional ifup/down setups. YaST handles those perfectly well so I think KDE has been told not to interfere/blacklist openSUSE. The issue beneath this in my opinion is whether KDE upstream wants to include system administration tools (printers, network, firewall, users, etc.) in System Settings or not. Obviously, it's better for SUSE if they don't, as we have YaST.
There may be a good reason for this, but a common complaint is that sub-pixel rendering for fonts is not turned on by default in opensuse in KDE, unlike in most distributions, resulting in ugly fonts.
Legal reasons (possible patent conflict with Microsoft's ClearType AFAIK), have a look at http://opensuse-community.org/SubpixelHinting. Works great for me. Regards, Tejas -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org