--===============1907253320==
Content-Type: multipart/signed;
  boundary="nextPart5517456.7tnA35U0hR";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart5517456.7tnA35U0hR
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
ebuild + the fact that we have to make them leave both aside doing some=20
strange tricks on the dependency resolution. Look at the eclass/ebuilds and=
=20
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=20
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=20
program of other parts that you want to install.

> Before this was solved by simply emerging kdebase but with the=20
> split, you will now need to decipher what packages that have been split=20
> 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 =3D e=
merge=20
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 do=
c=20
explaining more of these. Plus you can always look at the eclass+ebuilds to=
=20
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 progra=
ms.

The missing ones will be added thanks to users reports. Just rember that we=
're=20
in beta2.
=20
>
> 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.=
=20
There're more users happy of the split that users complaining (look at the=
=20
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=
=20
absumptions.=20
So please take some time to understand how everything really works before=20
saying that something is bad and something is good.


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

--nextPart5517456.7tnA35U0hR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCC/5cGHZ6cISxX/8RAoAXAKCRIFuRJ9rHHo5rq0BSTRk0fynySACgneRE
g1937HE58izZfeeQlHK4S/Q=
=fKjr
-----END PGP SIGNATURE-----

--nextPart5517456.7tnA35U0hR--

--===============1907253320==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1907253320==--