On Fri, Jan 23, 2009 at 10:41 AM, Jan Mette wrote:

Hi there,

i have just tried it 4 times to respond to this thread:

http://www.archlinux.org/pipermail/arch-dev-public/2009-January/010005.html

Although i have registered today, i get only a "not open for public" message that tells me i should respond to your mail address, so maybe i have no sufficient rights to post something on this list...

It would be very nice if you can forward my mail to the list.

I am just a "mailing list procrastinator" and have almost no experience with this stuff, sorry for bothering you and my dumbness :)

Hey Jan, Typically what people do is reply to the message and change to address to arch-general to transfer the thread there. I've sent this on to the dev list anyway. Cheers, Aaron

---------------------------------------------------------------------------------------------------------------------

...

Hey guys,

providing splitted KDE packages is one of most wanted feature request sine there was KDE in Arch. And people have good reasons demanding it. Let's have a look at the problem:

The KDE project does not provide source packages for every single application but they put them in some kind of categories. E.g. there are kdenetwork, kdemultimedia, kdegraphics etc.. So if you want an VNC client you have to install kdenetwork and you'll get an instant messanger, download manager, nvc server, samba client and others including their dependencies for free.

...

After 4.2 will hit [extra] I'd like to work on this. This will also be a good test case for the makepkg implementation.

...

My idea of splitting is to create one package for each app like kopete and not split by data, lib, docs etc.. Those packages will be members of a group; so pacamn -S kdenetwork still results in the same apps being installed.

And last but not least: You might wonder why we not just include kdemod. I had a little talk with funkyou about this. KDEmod/Chakra has different goals and philosophy and is not really compatible with the Arch way. So they'd like to keep doing their own thing.

Greetings,

Pierre

Hi there,

At first: sorry for not responding to the original thread. I have just registered on this ML, and i cannot reply to it...

As you may know i am the so-called "lead developer" of KDEmod, although i dont like those titles at all and all other people in our team seem to be much more capable than myself - so this is just that you can recognize me ;)

I have already talked to Pierre about the whole split stuff and want to add my view about it, and also set the record straight on some points he mentioned.

At first, the goals and philosophy of the KDE packages in extra and KDEmod are not very different, both are (now) aiming for split KDE modules. I also told Pierre that we can remove all of our backports from KDEmod (currently there is just one small backported patch in our KDE 4.2 packages) and keep it clean. We planned that anyway for the 4.2 version, as it is now completed enough to live without those backports.

From my point of view, there isnt a real difference in terms of goals and philosophy... And when KDEmod is not compatible to the Arch way, what about split KDE packages in extra? Are these conform to the Arch way then? If thats the case, i would like to know why... As i see it, splitting up KDE in Arch doesn't really conform to the Arch way anymore, at least as i understand "...without unnecessary additions, modifications, or complications..." and "...an elegant, minimalist approach..."

Oh, and i never said that we would like to continue doing our own thing, just to say that... We are absolutely open to make KDEmod more conform to Arch, and thats exactly what i told Pierre. We have also just started to port KDEmod to the new makepkg with split support, which we plan to use with the release of 4.2.1... All in all, KDEmod is also a good testcase for the split support in makepkg, and so far there have been no problems with it, good work :)

There is some more stuff i would like to add here, basically my view about the whole "split KDE packages in Archs extra repo" idea:

1. If you split up KDE in Arch, you will basically reinvent the wheel, including all mistakes we did during the past ~2 years, which will also affect the users of course. It will be the same learning effect that we had, repeated by someone else - and splitting up KDE is not as trivial as it may seem. You cannot do just one package per app for example. While this may work for kdenetwork, most other KDE modules have shared components that need something like a "-common" package, so this needs quite a lot of planning and testing. To outline the needed efforts: With KDE 4.2 we just have reached a point where we can say "ok, its really solid now", and that took a lot of time and efforts (since KDE3, to be exact).

2. Choice is better than two competing projects. Currently, Arch has the absolutely best selection of KDE packages available. We have KDE in extra, KDEmod, KDEmod KDE 3 packages and of course Tanis repo and Markc's daily SVN repo. The result of that is that users have a real choice... And from my experience there are also a lot of users who dont like split KDE packages, but just want the "plain default".

3. Our aim with KDEmod is to deliver a "high-class selection" of KDE packages, which are both suitable for users and developers. There are quite some KDE devs who are using our packages, because we are providing packaged debugging symbols for example, and because we are not "tied to any rules" we are also able to do weekly updates from the stable KDE branch and such stuff, which makes bug-hunting a lot easier.

4. We are 8 people and several contributors (who test and give feedback) who work on the KDEmod packages. This is a lot more manpower than it is available for Archs KDE packages - and i can guarentee that doing split packages with only 1-2 people is a lot of work, especially when it comes to testing packages and packaging a new major release.

5. If KDE in extra will be split, there will be two competing package sets and a lot of doubled efforts. This will maybe result in some confusion for the users, and in the end no one really gains something from it. It will also be more work for us, because we have to adapt our stuff to the changed KDE packages in extra.

Now, please dont misunderstand me here, but from my point of view the current plans are not very well-grounded and need some more communication, as they will lead to doubled efforts, confusion of users and of course a lot more complexity for packagers (like us). (oops, i am repeating myself, sorry...)

The two solutions i see are:

1. If people want split packages in Arch, we would be absolutely happy to make KDEmod (more) conform to Arch and then put it into [extra]. Of course we would also help maintaining it, if you guys accept people as devs who were not very active "the official way" before :) Oh, and if that would be the case, we would also need to discuss about makepkg support for -debug packages (i have already ported the debug patch to the new makepkg with split support), as these are quite a standard among distros and would attract a lot more people who like to use Arch + KDE, but miss some important features.

2. We can just continue doing what we did before, let users decide what they want to use and keep the choice. That would mean "standard" non-split KDE packages in [extra] and of course KDEmod as an alternative, with some more features and more agile developers who are not bound to any rules applying to Arch. Also, the argument that there are just too much dependencies for KDE in [extra] seem a bit like a personal thing of Pierre to me (no offence intended). I mean, the KDE 4.2 packages in extra are missing 6 dependencies so far, and these are really small and easy to add, and that doesnt justify splitting up KDE from my point of view.

I am quite unsure about which way to prefer, so i would like to read some opinions about that from you guys... However, i am slightly tending to option 2 = leave it like it is and let the users have their choice - of course with some more collaborating between us and you guys...

Greetings

Jan (aka funkyou)