From kde-core-devel Sun Feb 25 13:29:06 2007 From: Andras Mantia Date: Sun, 25 Feb 2007 13:29:06 +0000 To: kde-core-devel Subject: Re: organizing kdebase Message-Id: <200702251529.07196.amantia () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117241016705942 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1828510.Za0mQdDvYS" --nextPart1828510.Za0mQdDvYS Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 24 February 2007, Aaron J. Seigo wrote: > On February 24, 2007, Kevin Krammer wrote: > > If the signal to packager is that kdebase without tools is consider > > enough for a dependency of a kde-core metapackage, then tools like > > kdialog, kread/kwriteconfig need to be in runtime. > > > > If the signal is that this is purely a matter of internal > > organisation and that packages should treat binaries in tools like > > binaries in runtime, e.g. have them both in a kdebase-bin package, > > then I see no problem. > > i think this is up to packagers at the end of the day no matter what > we do. this simply helps categorize things "properly". a proper > kde-core metapackage would indeed include runtime/ and tools/ (and > apps/ too, imho), but the -minimal dependency- from kdebase for an > end-user application is runtime/. > > jakob is quite right about the oddness of including only some > scripting requirements and not others, but i figured i wouldn't go > there ... now that someone has, it's quite true as far as showing why > we don't shove every scripting support facility into runtime/ ... or > maybe we do and include things like the kommander runtime. > > speaking of kommander, i'd personally like to see it in > kdebase/tools/ (or runtime/tools/, whatever) so that it's more > dependably reliable. if we ship kdialog, not shipping kommander is a > bit odd. we provide kdialog in part because of xdialog, no doubt, but > kommander is ++xdialog so not having it there seems like we're > missing an opportunity. > > just imagine how much more popular kommander utilities would be if > everyone had the runtime? =3D) > > i'm cc'ing the kommander team as this is my invitation to them to > discuss this possibility. Somehow this mail did not reach the kommander list, but well, I reply=20 there as well, maybe they will get it. ;-) Unfortunately Kommander was=20 not ported at all to KDE4 at this moment, so its rather early to=20 discuss about where to move it. The reason behind the non-existant port=20 are various, I don't discuss here. But I can safely say that the goal=20 of the Kommander team is to have the executable part of the KDE=20 workspace and kdebase/tools or kdebase/runtimes would be a great place.=20 Kommander seems to be quite popular (100+scripts on kde-apps Kommander=20 section and some which are in other sections), so if we manage to port=20 in time for KDE4 (and solve the possible issues regarding security=20 raised by some devels), we believe it should be in kdebase in a place=20 where developers can rely that distributions will install it.=20 I think it all comes down to our policy and how we present this policy=20 to the packagers. If we say that a KDE installation must have kdelibs,=20 kdebase/runtime, kdebase/workspace and kdebase/utils(tools), but not=20 kdebase/apps (as those apps can have replacement ones in other places,=20 eg. another text editor, not KWrite), then it really doesn't matter if=20 kdialog and kommander is in utils or tools. What it matters is that it=20 is not in apps, which is not "mandatory". Andras =2D-=20 Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org --nextPart1828510.Za0mQdDvYS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBF4Y8jTQdfac6L/08RAoT0AJ4lGpu6hsQvnD3QEFwOOYT9ufTzRwCguM01 ay+B4eji6wCxcLJtlwuRTxI= =hjw7 -----END PGP SIGNATURE----- --nextPart1828510.Za0mQdDvYS--