[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Questions about splitting kdebase into a plethora of packages
From:       Simone Gotti <motaboy () gentoo ! org>
Date:       2005-02-10 23:41:06
Message-ID: 200502110037.48106.motaboy () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 10 February 2005 21:17, Lokheed wrote:
> I completely agree with you. Many of these issues are not addressed and
> should have been done first. I have seen this many times were users of
> Gentoo are not informed of changes or these blurbs are hidden among
> countless help files. Critical system changes go changed but the end
> user is most often not told about them. It becomes mind-boggling at
> times trying to track down information about a certain change (why?
> when? etc.)
>
> I also agree that this will be brutal to maintain and my cries to
> support one ebuild (kdebase) get answered with the common: "Its just to
> much to maintain both." Which my natural thought is: "It's too hard to
> maintain one extra ebuild?"
Yes. It's not the ebuild itself, it's all the work behind one monolithic 
ebuild + the fact that we have to make them leave both aside doing some 
strange tricks on the dependency resolution. Look at the eclass/ebuilds and 
you'll understand why.

> I believe the Gentoo devs are acting in their, I stress "their",
> interests here. They have no listened to the concerns of the end user
> and are hell bent on breaking KDE up into more than 300 ebuilds...all of
> which are listed under kdebase I might add.
We listened to them. Every concern was based on wrong absumptions that we 
demonstrated.

> The biggest problem is the meta ebuilds. kde-meta will pull in every
> known package of kde (including the additional packages outside of
> kdebase). If a user does not want kkdemultimedia, or kdeutils, that will
> break the meta ebuild and the user is forced to enter every package one
> by one.
Why this? You can always do emerge kdebase-meta, kdepim-meta + only the 
program of other parts that you want to install.

> Before this was solved by simply emerging kdebase but with the 
> split, you will now need to decipher what packages that have been split 
> from kdebase you will require, all the while entering them in manually,
> one by one.
As said in the previous line this is just like before (emerge kdebase = emerge 
kdebase-meta).

>
> Among other problems, users are directed towards rude replies when asked
> to submit requests to support the monolith kdebase in the future.
They weren't rude. We already replied to a lot of answer and there was a doc 
explaining more of these. Plus you can always look at the eclass+ebuilds to 
see how they works before saying that they are wrong and bad...

> It has been handled very poorly and I thought I was mad for seeing
> faults (the one above being critical) in the split.
Which one?

>
>  From what I have read and the replies, it appears KDE does not have
> really any official stance but my main concern is the stability. I have
> yet to read about stability issues in splitting up kde like this. I was
> under the assumption that some components (kcontrol for example) where
> critical for kde to function, but I have not read anything to disprove
> or prove this.
It's critical. And if you look at the ebuilds it's a dep of a lot of programs.

The missing ones will be added thanks to users reports. Just rember that we're 
in beta2.
 
>
> Anyway thanks for the reply. I believe you understand the users dilemma
> because you support them. Most of these devs are thinking along the
> lines of programmers and we all know that the engineer has nothing in
> common with the end user.
We doesn't gain anything going against what the users wants. Just remember. 
There're more users happy of the split that users complaining (look at the 
forums). the split was done because a lot of users were asking for this.

And I'm repeating this again, you said some bad things to us based on wrong 
absumptions. 
So please take some time to understand how everything really works before 
saying that something is bad and something is good.


Bye!
-- 
Simone Gotti - Gentoo Developer
<motaboy@gentoo.org>
http://kde-bluetooth.sf.net

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]