From kde-core-devel  Mon Nov 20 12:30:09 2006
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Mon, 20 Nov 2006 12:30:09 +0000
To: kde-core-devel
Subject: Re: Okular moving
Message-Id: <200611201330.09181.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116402586900833
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2513446.LDmZLrmI1x"

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

On Sunday 19 November 2006 21:58, Leo Savernik wrote:
> Am Samstag, 18. November 2006 16:32 schrieb Kevin Krammer:

> A useful basic KDE (3.x) distribution comprises of the packages kdelibs
> kdebase kdeaccessibility kdeadmin kdegraphics kdemultimedia kdenetwork
> kdepim kdeutils kdeaddons (leaving aside whether packagers split those or
> distribute them as they are).

We seem to have a different definition of "basic"
Part of each of those modules are basic from my point of view, however=20
unfortunately they are usually just one package and thus have loads of=20
applications that are in no way "basic" desktop

> If you consider a KDE distribution comprising of only kdelibs+kdebase,
> we're at Microsoft Windows level, functionality wise. I'd be surprised if
> this is the direction KDE 4 is heading towards.

I don't consider kdelibs+kdebase suitable, but since you insisted that PDF=
=20
viewing is so important, it has to be there, right?

> > Anything else is a matter of package dependencies, where it doesn't
> > matter which source module an application is from. Actually, since the
> > packaging of big source modules is quite broken on some distros, having
> > the viewers in KEG will allow a fullfeatured KDE desktop experience with
> > less installation size, meaning fewer applications filling the K-menu
>
> The really big problem with this approach is that people have to know
> beforehand which application they have to install to get feature X.

Actually no, that's the point of a package dependency, isn't it?
If a user installs the KDE desktop package, e.g. usually a meta package=20
called "kde" or "kde-desktop", it will depend on the packages that make up =
a=20
full-featured KDE desktop. If it does depend on kdegraphics or just KPDF is=
=20
not a teeny weeny bit different to the user at install time, but gets them=
=20
less crowded K-menu at runtime.

> Do you=20
> think that Joe User has any idea the he has to install an application
> called Okular before he can view pdfs? Especially as he didn't have to
> worry about this in KDE 3.x times where it was sufficient to install all
> kde* packages and not missing out anything.

=46irst, I said that the viewer would always be part of the "desktop"=20
dependencies. Second, if the user installs all kde* packages, there will=20
hardly be a difference between now and then, they will get everything (well=
,=20
unless the meta package for kde extragear is not prefixed with kde)

Anyway. Since source repository organisation currently implies installation=
=20
modules and this is not likely to change anytime soon, we should just make=
=20
KEG an official module and have it released (additionally to their own=20
intermediate releases) as one hugh package (poeple other than me seem to li=
ke=20
hugh packages) whenever KDE releases.

Everybody gets "everything of KDE" and everybody is happy and we do no long=
er=20
need to discuss into which module to put apps.

Cheers,
Kevin

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

--nextPart2513446.LDmZLrmI1x
Content-Type: application/pgp-signature

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

iD8DBQBFYZ/RnKMhG6pzZJIRAmJMAJ4iU4pWxkylnnt1L5gGsNeZcMnUswCfZatc
5sXwept/50DbOUVXDLjJFyg=
=OCQW
-----END PGP SIGNATURE-----

--nextPart2513446.LDmZLrmI1x--