| 1 |
Hi all, |
| 2 |
|
| 3 |
KDE 2.2 is around the corner (for a long time now :-(), but it'll be here at |
| 4 |
some point and should be easy enough to introduce into gentoo because we |
| 5 |
already have kde-2.2_beta1. |
| 6 |
|
| 7 |
Once that happens, we'll be able to add the latest versions of all |
| 8 |
2.2-dependant kde apps, which are often enough the only versions. |
| 9 |
|
| 10 |
In fact, since at least 95% of all kde apps are standard configure/make/make |
| 11 |
install stuff, adding them would be very easy and quick. Also, dependencies |
| 12 |
will be easy to track in creating ebuilds, since a working kdelibs present on |
| 13 |
the system accounts for almost everyhting except gcc. (There are, of course, |
| 14 |
apps which require other libs.) |
| 15 |
|
| 16 |
Even if we don't do a massive addition of hundreds of apps, most of them will |
| 17 |
be added sometime, one by one, as our user base grows. |
| 18 |
|
| 19 |
The problem is with categories. There are many hundreds if not thousands of |
| 20 |
apps registered on apps.kde.com, in 20+ categories. Obviously we can't put |
| 21 |
them all into kde-apps. But eventually most of them will acquire ebuilds. So |
| 22 |
I think we need to weigh sub-categories etc. |
| 23 |
|
| 24 |
|
| 25 |
Possible solutions: |
| 26 |
|
| 27 |
1. Put everything into kde-apps, as it is now. |
| 28 |
Problems: as stated at beginning of post, too many ebuilds in one general |
| 29 |
category. |
| 30 |
Benefits: completely compatible with existing structure, makes progressive |
| 31 |
adding of ebuilds easy. |
| 32 |
|
| 33 |
2. Add just two or three kde-* categories, like we have with gnome. |
| 34 |
Problems: still potentially too many programs in each category, and it is |
| 35 |
unclear what these two or three new categories should be (apps.kde.com has |
| 36 |
more than 20 categories, and upto 15 sub-categories for each fo those). |
| 37 |
Benefits: Completely compatible with current structure. Doesn't affect |
| 38 |
existing ebuilds. |
| 39 |
|
| 40 |
3. Dismantle kde-*. Put kde-base into x11-wm (or rather x11-de), koffice into |
| 41 |
app-office... This is what FreeBSD does with its ports. |
| 42 |
Problems: even more uncompatible with current structure, breaks existing |
| 43 |
categories. |
| 44 |
Benefits: may be the best solution without creating many new categories. |
| 45 |
|
| 46 |
4. Create second-level categories, i.e. kde-apps/office, kde-apps/sound... |
| 47 |
Problems: uncompatible with current structure, duplication of categories |
| 48 |
(kind of like FHS - /usr, /usr/local...) which, when dealing with ebuilds |
| 49 |
that optionally depend on kde, is very awkward. And a user searching for e.g. |
| 50 |
all cdr apps would have to check apps-cdr, kde-apps/apps-cdr, |
| 51 |
gnome-apps/apps-cdr... |
| 52 |
Benefits: easy to categorize and find specific apps, fewest apps in each |
| 53 |
category without too many categories in the top dir. |
| 54 |
|
| 55 |
5. Don't add the kde apps, ignore the issue for now. Concentrate on improving |
| 56 |
existing ebuilds. |
| 57 |
|
| 58 |
|
| 59 |
|
| 60 |
So, what do you think? Please comment! |
| 61 |
|
| 62 |
|
| 63 |
|
| 64 |
-- |
| 65 |
|
| 66 |
Dan Armak |
| 67 |
Gentoo Linux Developer, Desktop Team |
| 68 |
Matan, Israel |
Archives