From kde-core-devel  Tue Nov 21 11:18:20 2006
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Tue, 21 Nov 2006 11:18:20 +0000
To: kde-core-devel
Subject: Re: Okular moving
Message-Id: <200611211218.20708.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116410797525786
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart11197291.GbdbhJRImf"

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

On Monday 20 November 2006 21:05, Leo Savernik wrote:

> Yeah, but then we're totally at the mercy of distributors to assemble
> suitable "kde" metapackages. Some will get it right and others will blow
> it.

Not much difference to our current situation, we are always at their "mercy"

> The current grouping gives invaluable hints to packagers which applicatio=
ns
> to bundle into meta-packages. If essential applications are moved out of
> "KDE - The Desktop Environment", we again have to rely on distributors to
> grab those essentials from KEG and link them in their meta-packages.

It mainly depends if packagers use the source packages we release or if the=
y=20
do direct checkouts based on tags. In the first case repository organisatio=
n=20
can be different to release grouing, in the later we have to adjust=20
repository organisation to release needs.

> Even worse, it will lead to a segregation of our user base as distributor=
 x
> may choose suitable application A, while distributor y may choose suitable
> application B for the same purpose.

I am sorry to tell you, but distributors already do this. There can be huge=
=20
differences between what we release and what the users get.
We usually only hear about the neat things, like SUSE's new K-menu thingy, =
we=20
usually do not hear about things like patching KMail's default mail directo=
ry=20
from ~/Mail to ~/.Mail (instead of using an appropriate default config), or=
=20
the things Waldo mentioned in his Portland talk at aKademy, etc

Assuming KDE, as in software we release and intended user experience, is th=
e=20
same KDE, as in software the users install and actual user experience, woul=
d=20
be ignoring the empirical evidence.

> KEG has become way too big to install it as a whole. Given how bitchy it =
is
> to extract out a single app and build it (has this improved with cmake?),
> and given that users who want to gain functionality selectively again have
> to know the name of the package, this suggestion seems to lead to more
> disadvantages than advantages.

You mean big compared to such tiny modules as kdegames? ;)

> > Everybody gets "everything of KDE" and everybody is happy and we do no
> > longer need to discuss into which module to put apps.
>
> <irony detector ringing>

Good :)

Cheers,
Kevin
=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart11197291.GbdbhJRImf
Content-Type: application/pgp-signature

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

iD8DBQBFYuB8nKMhG6pzZJIRAlc8AJ97rkR+Zx2Oovqe51Lhe33/kwtnDwCggRQL
E/Ne0OdbgdnIZ95dxydV904=
=yJPb
-----END PGP SIGNATURE-----

--nextPart11197291.GbdbhJRImf--