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

List:       kde-core-devel
Subject:    Re: Fwd: Re: How to distribute kdedb plugins
From:       George Staikos <staikos () kde ! org>
Date:       2001-03-29 0:26:24
[Download RAW message or body]

On Wednesday 28 March 2001 21:10, Henrik Johnson wrote:

> I'm pretty sure you can't redistribute the .h files and the clntsh
> library from Oracle. But I fail to see the problem. You run configure,
> configure don't find Oracle, configure wont compile the plugin. It's not
> like the entire compilation of kdelibs fails. I keep coming back to PHP
> in Mandrake which have a separate package for using oracle. This is the
> whole point of plugins: To load optional modules. If you don't have the
> oracle client installed you can't use it off course. Still it is better
> to have it available, I know there are a lot of people in corporation
> that still need to use Oracle because of corporate policy. And to pee a
> little in the wind I think it still has a little advantage over the free
> alternatives, don't take this flame. It's just a personal oppinion I
> still love MySQL if people wont die if the DB is corrupted.

  You're missing the point here.  Of course nothing will crash or die.  It's 
desirable to have all plugins compiled and shipped with packages.  This means 
that the distro has to install every commercial database sdk that someone 
writes a plugin for when they compile kdelibs.  Or we could separate out the 
plugins and provide source packages so that a user could compile these on his 
own.  MySQL is easy.  If a distro already supports Oracle, then that's easy.  
However, are they going to go to the trouble of directly supporting _every_ 
database that there is a plugin for?  

   Even if oracle lets you ship part of their sdk, will IBM?  Will Informix?  
Will Xxyyzz company?  It's _easy_ to do as Waldo described.  Make separate 
packages for plugins and (what I want) make them buildable individually.  
That way a user can simply build a new module for his own database if his 
distro doesn't do it for him.  No package dependency problems, no selective 
building by the distro.  This is similar to something that has been done in 
commercial environments before as well.  They ship .o files that can be 
linked with whatever libraries you want.  No dependencies, no issues with the 
vendor having to support 10 different products that they normally have 
nothing to do with.

  If you rely on ./configure to decide what modules get compiled, then .rpm 
users will end up with only the modules that the distro happens to 
support/feels like supporting when they build.  You also have BC issues to 
contend with if the database happens to break BC across versions.   Now the 
user has to download the entire kdelibs and rebuild.  That's just silly.  If 
we package the modules separately and make them easily buildable outside the 
kdelibs tree, then the user can easily add support for his favorite database 
when the distro didn't do so.

  I still refuse to believe that distro's are going to happily go along and 
support every commercial database that we happen to write a kdedb module for.

> > > 3. if the dlload fails ask the user to check for the presence of
> > > libclntsh.so?
>
> Just say you can't load the plugin, I'm sure the whole kde wont crash if
> a kdb plugin fails to load?

   Of course... that's easy.  

-- 

George Staikos

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