organizing kdebase

[Kevin Krammer]

On Saturday 24 February 2007 14:55, Jakob Petsovits wrote:
> On Friday, 23. February 2007, David Faure wrote:
> > On Thursday 22 February 2007, Aaron J. Seigo wrote:
> > > On February 22, 2007, David Faure wrote:
> > > > On Thursday 22 February 2007, Aaron J. Seigo wrote:
> > >
> > > oh, it's not about C++. if Ruby or Python apps used these tools, that'd
> > > be enough. the language used is not relevant, the kind of application
> > > is.
> > >
> > > let's say i did an `$PACKAGE_MANAGER install kfoo`, that should pull in
> > > kdelibs and kdebase/runtime. the latter should have only what is really
> > > the runtime for such applications. kfoo, regardless of what language it
> > > is written in, should not be using kwriteconfig.
> >
> > ... unless it's written in bash.
> >
> > That's the point. If (or given that) we provide enough tools, you can
> > make useful addons in shell scripts using kdialog, kread/writeconfig,
> > etc. Those scripts have runtime requirements: kdebase/runtime.

I think I agree with David, but it mostly depends on how it is going to be 
packaged.

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.

> Actually, this made me wonder about the difference between tools made for
> shell scripting and language bindings. Like in:
>
> - You need kdebindings to execute Ruby/Python/whatever apps
> - You need the kommander runtime environment to execute kommander apps
> - You need tools/ to execute KDE-enabled shell scripts
>
> From that point of view, tools/ doesn't seem to be anything different than
> the language bindings for shell scripts. So if you include tools/ in
> runtime/, where do you stop? Shouldn't the kommander runtime also be in
> there? Don't we need the Ruby and Python bindings to execute such apps?
> After all, those are scripts as well, and can similarly be downloaded,
> written and run on-the-fly without needing to compile anything, or make a
> binary package, or set up your standard C++ development environment.
>
> Why should we want shell-enabling tools in runtime/, but leave out Ruby in
> the same breath? I think Aaron's reasoning was not so far off in this
> respect.

From my point of view the main difference is that scripts written in Python or 
Ruby already have the respective language's runtime as a dependency, while a 
shell script is usually considered to be without dependecies.

As a matter of fact, a couple of the xdg-utils scripts (xdg-su, 
xdg-file-dialogs) are on hold because the GNOME equivalent of certain KDE 
tools are not always present in GNOME default installs, so as I said above it 
really depends on how the packagers are going to treat our restructuring.

Though it might be worthwhile to think about a kdebindings/shell collection of 
really sophisticated commandline tools and a recommendation for packagers to 
depend their default meta packages on it.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070224/f6b24bf3/attachment.sig>