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

List:       koffice-devel
Subject:    Re: Adding a README.packagers to koffice
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2005-11-18 10:13:47
Message-ID: 437DA95B.90403 () iidea ! pl
[Download RAW message or body]

Cyrille Berger said the following, On 2005-11-18 00:09:
>>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...
> 

I am with Cyrille here: being not a big fan of:

1. freeing packagers from their work by duplicating pacakge management's 
checks in our code and executing this on every plugin's loading

2. accepting a following downgrade: to only provide a binary (yes/no) 
information if the plugin has been succesfully loaded. If I had to depend jsut 
on dlopen() failure/success, at most I can provide a _non_i18n'd_ message 
found somewhere that e.g. "libxyz.so: could not find symbol 
_XYZ_GFWEGEW@VWE___" - not very user friendly.

So I am rather fan of relying on built-in package management which tells the 
user (on installation time) about minimal version of a low-level libraries 
needed for the plugin, with nice i18n'd text (if the distribution is prepared 
to do so), with _standard_ GUI.

What could be a nightmare from user's POV is a message like "install some more 
packages" on app's runtime, when she was really happy ith automatic 
dependencies resolution in tools like apt or yum or derivatives.

In general distribution (not just in Debian-like) a given library, say 
libFOOLowlevel, user can uninstal it without a warning, because in the model 
mentioned by Thomas, FOOPlugin has only a weak dependency on libFOOLowlevel. 
Such deps are great but not available everywhere.
So such uninstallation this will silently break FOOPlugin. Moreover, in the 
plugin's code we're unable to display a message telling a user 'what a pacakge 
is required', exactly by name, because naming is not (yet?) portable across 
distributions.

IIRC 'suggested packages' idea is not even in LSB yet, right?

BTW, In particular, README.packagers could contain an updated version of this 
text:
http://kexi-project.org/wiki/wikiview/index.php?HintsForMakingKexiPackages



One note for Cyrille about following names:

libkoffice-kross
libkoffice-kross-python
libkoffice-kross-ruby

I would replace 'kross' with 'scripting'. I can see at least SUSE has a habit 
to name packages without geek names (like 'kross') to make user's live easier, 
so why not to simplify this out of the box?

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi Developer:
      http://www.kexi-project.org | http://koffice.org/kexi
  Kexi support:
      http://www.kexi-project.org/support.html
  KDE3, KDE4 libraries for developing MS Windows applications:
      http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32
_______________________________________________
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]