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

List:       koffice-devel
Subject:    Re: Adding a README.packagers to koffice
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2005-11-17 23:09:19
Message-ID: 200511180009.19444.cberger () cberger ! net
[Download RAW message or body]

> From where I stand the dynamic loading of just the plugin which would then
> crash if no python is actually there[1] is a mistake in implementation
> which should be reconsidered.
> Effectively I'd say that the dynamic binding of the plugins for ruby/etc
> should not be dynamic, just their successfull loading should be.

it doesn't crash, the dllopen failed that's all.

> > 2) to detect if a scripting language is avaiable and if it should be
> > offered Kross would need to load first all interpreter-plugins to ask
> > them if they found a supported/installed interpreter. So, it would
> > decrease the startup-time (at least a bit) to just ask for a simple
> > boolean value...
>
> Yeah, doing a stat("/usr/bin/python") indeed will ensure the startup time
> will triple, at minimum :P
> </sarcasm>
well /usr/bin/python can be not found and libpython be available, so we need 
to : find where all the librairies can be in the system (I know most are 
in /usr/lib or /usr/lib64, but we want something robust), and we must check 
for the python version that was linked to the plugin, well it's not that 
difficult, but it can become a mess in a few second. And having two plugins, 
one to check if the second one is loadable, is adding unnecesserary 
complexity to the code, and adding more source of bugs.

Whereas, if the package holding kross have a list of dependency associate with 
it, then we are sure that libpython is intended to be present (no plugin 
should make an application crash, ever, ever). And from an user point of 
view, I espect that a package, telling that it include python/or ruby 
scripting, will work right out of the box (as a dev, I don't care, I will 
never have a stable koffice package).

> > While it would be possible, I fail to see a reason
>
> You do?
> What about making it easier to install and making taking away the risks
> this initial thread started out with.
> It is indeed good practice to make it easier on packagers, for the plain
> and simple reason that it will take away complaints and to make sure you
> don't spent hours on weird bug reports you can't reproduce.
>
> As a simple example; take how in the most recent dot article about KOffice
> people complained about KWord crashing a lot.
well a lot of people complained that koffice has a lot too much dependency...

> It turned out that gentoo 
> had a packaging problem.  Which really is the worst possible reason for
> bad press about KOffice.
>
so adding a bad hack, which will work on 1 distribution out of 2, to check if 
an intepreter is available is a better way to go... I am sure, I missed 
something...

and to solve all those issue, I suggest we have a big package will all 
librairies that koffice use, this way we avoid all problems of 
incompatibility between versions. (my turn to be sarcastic).

-- 
--- Cyrille Berger ---
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]