On Fri, Jan 23, 2009 at 10:41 AM, Jan Mette <[email protected]> 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) >
