--nextPart1715818.vXIT3GxIbf
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 real=
ly
> > > 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=
=20
packaged.

If the signal to packager is that kdebase without tools is consider enough =
for=20
a dependency of a kde-core metapackage, then tools like kdialog,=20
kread/kwriteconfig need to be in runtime.

If the signal is that this is purely a matter of internal organisation and=
=20
that packages should treat binaries in tools like binaries in runtime, e.g.=
=20
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.

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

As a matter of fact, a couple of the xdg-utils scripts (xdg-su,=20
xdg-file-dialogs) are on hold because the GNOME equivalent of certain KDE=20
tools are not always present in GNOME default installs, so as I said above =
it=20
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=20
really sophisticated commandline tools and a recommendation for packagers t=
o=20
depend their default meta packages on it.

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

--nextPart1715818.vXIT3GxIbf
Content-Type: application/pgp-signature

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

iD8DBQBF4EhmnKMhG6pzZJIRAvlwAJsG43PHWQIY3K8rYTb93/WWWjuyywCfUrK2
ZbghMKcHLEJhZcoPFeIiO/s=
=eqBl
-----END PGP SIGNATURE-----

--nextPart1715818.vXIT3GxIbf--