[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: organizing kdebase
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: 2007-02-24 14:15:02
Message-ID: 200702241515.02388.kevin.krammer () gmx ! at
[Download RAW message or body]
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
[Attachment #3 (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic