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

List:       kde-core-devel
Subject:    Re: Proposal: package split
From:       Harri Porten <porten () tu-harburg ! de>
Date:       1999-10-03 23:27:48
[Download RAW message or body]

"Dirk A. Mueller" wrote:
> 
> Harri Porten <porten@tu-harburg.de> wrote:
> 
> > IRC client A, B and C should fairly compete. If A sucks and B is not
> > maintained anymore C will make the race.
> 
> right, but how do we honor this if A, B and C are distributed equally?
> If C makes the race, then C should be default and the others
> alternatives, which could be installed additionally or alternatively.

All three of them will be on ftp.kde.org or a distribution's CD. We
don't call one of them "default" as long as they are all stable and
compile. Of course, the distributor might decide to put one of them into
his typical install set. But the user can simply use a setup tool to
remove A and install B.

> On the other side, the more different files a user has to install, the
> more difficult will it for him/her to figure out what's necessary or
> what's suitable for his/her needs. So providing a poweful yet
> userfriendly default is always a good way to go.

Everything exceeding a mimimum working environment (kdebase) should be
customisable. Besides that, the distributor will provide a reasonable
setup like they do by adding Gimp, Emacs etc.

> I.e. kvt is installed as well as konsole. As konsole is considered to
> be better, why don't we install only konsole as default, but still
> giving the user the choice by providing kvt ?

That concerns the base system where we always will have to give a
preference to one alternative.

> Userfriendly is both giving multiple ways of doing the same thing as
> well as giving a default which can be easily figured out and used.

Ok. If you insist on providing a default combination mark certain apps
as recommended, put them into one directory, list or one Mega RPM for
people with enough bandwith.
But: why do we put kab, karm, kcalc, kcharselectkdf, kedit/kwrite,
kfloppy,
khexedit, kjots, klipper, kljettool, klpq, knotes, kpm, ktimemon, ktop
and ktreebrowser into a non-divideable package called kdeutils ? I fail
to see what they have in common. Part of them are highly specialized and
don't compile on every platform.

> That's the point. We should remove the stuff that has been replaced by
> a superiour app from default installation (making the "core"
> distribution smaller, thereby easier to maintain for us and easier to
> install for lowmem/lowspace systems) and provide them in some other
> "themed" packages.

If "core" would be kdebase I'd agree. Anything beyond that is different.

Another example hopefully proving my point (and to get away from the
duplication topic): kiconedit in kdegraphics. The author is gone and
left behind a lot of work for volunteers like you and me. We are forced
to fix every compile problem (bugs aside) in order to save the whole
kdegraphics package.
If it would be seperate it wouldn't cause us any trouble. If someone
volunteers to maintain it - fine - if not - good bye !

Why did we release a kdegraphics-1.1.2.tar.bz2 package although only
kdvi was touched since KDE 1.1.1 (IIRC). If kdvi, kfax, kfract,
kghostview, kiconedit, kpaint, ksnapshot and kview were deposited
separately on a ftp server (with their version number in the filename)
the whole thing would be much more transparent to people interested in
upgrading.

> > A much stronger one IMO is the question why a KDE 1.1.1 user has to
> > fetch a 3 MB kdenetwork package if he just wants to upgrade to kbiff
> > from 1.1.2.
> 
> you see, we're talking about the same thing, but still from two
> different viewpoints ;-)

I'm not really sure about that ... ;)

Harri.

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