kde needs mysql-server ??

[Manuel Wolfshant]

Hey

    Do we really need mysql-server on a _desktop_ running kde ?

[root@pc37 tmp]# rpm -q --whatrequires mysql-server
akonadi-1.0.0-3.fc10.i386
[root@pc37 tmp]# rpm -q --whatrequires akonadi-1.0.0-3.fc10.i386
no package requires akonadi-1.0.0-3.fc10.i386
[root@pc37 tmp]# rpm -e akonadi
error: Failed dependencies:
        libakonadiprotocolinternals.so.1 is needed by (installed) 
kdepimlibs-4.1.2-2.fc10.i386
[root@pc37 tmp]# rpm -q --whatrequires libakonadiprotocolinternals.so.1
akonadi-1.0.0-3.fc10.i386
kdepimlibs-4.1.2-2.fc10.i386
[root@pc37 tmp]# rpm -q --whatrequires akonadi
no package requires akonadi
[root@pc37 tmp]# rpm -q --whatrequires kdepimlibs
kdebase-runtime-4.1.2-5.fc10.i386
kdebase-libs-4.1.2-5.fc10.i386

Guess what requires kdebase-[libs|runtime] :)

I know that hard disk space is less expensive than it used to be, but....

[Rex Dieter]

Manuel Wolfshant wrote:

>      Do we really need mysql-server on a _desktop_ running kde ?
>  
>  [root@pc37 tmp]# rpm -q --whatrequires mysql-server
>  akonadi-1.0.0-3.fc10.i386 
In short (atm), yes:
http://techbase.kde.org/Projects/PIM/Akonadi

-- Rex

[Enrico Scholz]

Rex Dieter <rdieter(a)math.unl.edu&gt; writes:

> >     Do we really need mysql-server on a _desktop_ running kde ?
> > 
> > [root@pc37 tmp]# rpm -q --whatrequires mysql-server
> > akonadi-1.0.0-3.fc10.i386
>
>  In short (atm), yes:
>  http://techbase.kde.org/Projects/PIM/Akonadi 
Do you mean:

http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...

?  --> akonadi doees not need a local mysql-server but can use a mysql
server running somewhere else.


Enrico

[Rex Dieter]

Enrico Scholz wrote:

>  Do you mean:
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...

>  ?  --> akonadi doees not need a local mysql-server but can use a
> mysql
>  server running somewhere else. 
Theoretically, yes.  The default config is to use a local one, however.

-- Rex

[Christopher Stone]

On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:

>  Enrico Scholz wrote:
>
>  > Do you mean:
>
>
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
>  > ?  --> akonadi doees not need a local mysql-server but can use a mysql
>  > server running somewhere else.
>
>  Theoretically, yes.  The default config is to use a local one, however.
>
>  -- Rex
>
>  
mysql-server should not be a requirement then.  If it is possible to run the
server on another machine, then the mysql-server should be removed from the
Requires.

I do the exact same thing with one of my packages, poker-server.
poker-server *requires* a mysql-server, but does not require that it be run
on the same machine.  Therefore mysql-server should *NOT* be in the Requires
list.

[Rex Dieter]

Christopher Stone wrote:

>  On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter
> <rdieter(a)math.unl.edu&gt; wrote:
> > Enrico Scholz wrote:
> > > Do you mean: 
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
> > > ?  --> akonadi doees not need a local mysql-server but
> can use a mysql
> > > server running somewhere else.
> >
> > Theoretically, yes.  The default config is to use a local one, however. 
>  mysql-server should not be a requirement then.  If it is possible to
> run
>  the server on another machine, then the mysql-server should be removed
>  from the Requires. 
And make default config not work?  It's a balancing act, where there is no
100% correct solution, I'm afraid.

Soft dependencies, could theoretically help in cases like this too.

-- Rex

[Rex Dieter]

Rex Dieter wrote:

>  Christopher Stone wrote:
>  
> > On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:
> >> Enrico Scholz wrote:
> >> > Do you mean:
>  
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
> >> > ?  --> akonadi doees not need a local mysql-server
> but can use a mysql
> >> > server running somewhere else.
> >>
> >> Theoretically, yes.  The default config is to use a local one, however.
>  
> > mysql-server should not be a requirement then.  If it is possible to run
> > the server on another machine, then the mysql-server should be removed
> > from the Requires.
>  
>  And make default config not work?  It's a balancing act, where there is no
>  100% correct solution, I'm afraid. 
OK, discussed with fellow kde-sig'ers, we'll drop the hard dependency *for
now*.  Deciding factors included:
* nothing in fedora (and kde-4.1.x) actively uses akonadi yet.
* (bonus) mysql-server is big, omitting will save us some live image space

When kdepim-4.2.0 lands, we'll re-evaluate.

-- Rex

[Manuel Wolfshant]

On 10/22/2008 11:10 PM, Rex Dieter wrote:
>  Rex Dieter wrote:
>
>    
> > Christopher Stone wrote:
> >
> >     
> >> On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:
> >>       
> >>> Enrico Scholz wrote:
> >>>         
> >>>> Do you mean:
> >>>>           
> >     
>
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
>    
> >>>> ?  --> akonadi doees not need a local mysql-server but can use a
> mysql
> >>>> server running somewhere else.
> >>>>           
> >>> Theoretically, yes.  The default config is to use a local one, however.
> >>>         
> >> mysql-server should not be a requirement then.  If it is possible to run
> >> the server on another machine, then the mysql-server should be removed
> >> from the Requires.
> >>       
> > And make default config not work?  It's a balancing act, where there is no
> > 100% correct solution, I'm afraid.
> >     
>
>  OK, discussed with fellow kde-sig'ers, we'll drop the hard dependency *for
>  now*.   
thanks

>  Deciding factors included:
>  * [...]
>  * (bonus) mysql-server is big, 
THAT is the reason for my initial question

[Rares Aioanei]

Rex Dieter wrote:
>  Enrico Scholz wrote:
>
>    
> > Do you mean:
> >     
>
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
>
>    
> > ?  --> akonadi doees not need a local mysql-server but can use a mysql
> > server running somewhere else.
> >     
>
>  Theoretically, yes.  The default config is to use a local one, however.
>
>  -- Rex
>
>     
Try removing mysql-server and see how many important packages it pulls 
after it...that is, important for a desktop user.

[Rahul Sundaram]

Rex Dieter wrote:
>  Enrico Scholz wrote:
>  
> > Do you mean:
>
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
>
> > ?  --> akonadi doees not need a local mysql-server but can use a mysql
> > server running somewhere else.
>  
>  Theoretically, yes.  The default config is to use a local one, however. 
Then, instead of a direct dependency, it might be better to add the 
package to the comps group, leaving the users to remove the package if 
it is not required for their local configuration.

Rahul

[Rex Dieter]

Rahul Sundaram wrote:

>  Rex Dieter wrote:
> > Enrico Scholz wrote:
> > 
> >> Do you mean:
> >
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
> >> ?  --> akonadi doees not need a local mysql-server but can
> use a mysql
> >> server running somewhere else.
> > 
> > Theoretically, yes.  The default config is to use a local one, however.
>  
>  Then, instead of a direct dependency, it might be better to add the
>  package to the comps group, leaving the users to remove the package if
>  it is not required for their local configuration. 
That's an option we'll consider.

-- Rex

[James Antill]

On Wed, 2008-10-22 at 22:46 +0530, Rahul Sundaram wrote:
>  Rex Dieter wrote:
>  > Enrico Scholz wrote:
>  > 
>  >> Do you mean:
>  >
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
>
>  >> ?  --> akonadi doees not need a local mysql-server but can use a mysql
>  >> server running somewhere else.
>  > 
>  > Theoretically, yes.  The default config is to use a local one, however.
>  
>  Then, instead of a direct dependency, it might be better to add the 
>  package to the comps group, leaving the users to remove the package if 
>  it is not required for their local configuration. 
 Queue BZs about the fact that "yum groupremove KDE" now deletes the
local mysql-server in 3, 2, ...

-- 
James Antill <james.antill(a)redhat.com&gt;
Red Hat

[Rex Dieter]

James Antill wrote:

>   Queue BZs about the fact that "yum groupremove KDE" now
> deletes the
>  local mysql-server in 3, 2, ... 
it already removes a bunch of stuff that overlaps with other desktops too,
that's not news.

-- Rex

[Rahul Sundaram]

James Antill wrote:
>  On Wed, 2008-10-22 at 22:46 +0530, Rahul Sundaram wrote:
> > Rex Dieter wrote:
> >> Enrico Scholz wrote:
> >>
> >>> Do you mean:
> >>
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MyS...
>
> >>> ?  --> akonadi doees not need a local mysql-server but can use a mysql
> >>> server running somewhere else.
> >> Theoretically, yes.  The default config is to use a local one, however.
> > Then, instead of a direct dependency, it might be better to add the 
> > package to the comps group, leaving the users to remove the package if 
> > it is not required for their local configuration.
>  
>   Queue BZs about the fact that "yum groupremove KDE" now deletes the
>  local mysql-server in 3, 2, ... 
This is just one of the symptom of the general issue of how groups are 
defined. That needs to be fixed somehow.

Rahul

[Rex Dieter]

Manuel Wolfshant wrote:

>      Do we really need mysql-server on a _desktop_ running kde ?
fyi, backend storage is a wee bit of a mess in kde-land at the moment, see
http://pusling.com/blog/?p=85

-- Rex

[Juha Tuomala]

On Wednesday 22 October 2008 13:46:02 Manuel Wolfshant wrote:
>  
>      Do we really need mysql-server on a _desktop_ running kde ?
>   
A related discussion in dot a while ago:

  http://dot.kde.org/1209500572/1209540984/


Tuju

-- 
Varo hattupäisiä autoilijoita.

[Muayyad AlSadi]

they must consider sqlite, it's very crazy for desktop applications
like amarok or contacts ..etc. to serve a database and to connect to
itself

[Matthew Woehlke]

Muayyad AlSadi wrote:
>  they must consider sqlite, it's very crazy for desktop
> applications
>  like amarok or contacts ..etc. to serve a database and to connect to
>  itself 
Ah, did you actually read http://techbase.kde.org/Projects/PIM/Akonadi? 
(Summary: they *did* consider sqlite, at least according to the FAQ)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When on POSIX, do as POSIX mandates.

[Muayyad AlSadi]

>  Ah, did you actually read
> http://techbase.kde.org/Projects/PIM/Akonadi?
>  (Summary: they *did* consider sqlite, at least according to the FAQ)
>  
yes I read it,


> Why not use sqlite?
>  We tried. Really. It can't handle the concurrent access very well, in the best case
> this means very slow operations, but we've also seen deadlocks and failing
> transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead
> of MySQL is no problem. 
not convinced

I know that SQLite is not officiant for heavy concurrency
from http://www.sqlite.org/whentouse.html
Situations Where Another RDBMS May Work Better
High Concurrency

SQLite uses reader/writer locks on the entire database file. That
means if any process is reading from any part of the database, all
other processes are prevented from writing any other part of the
database. Similarly, if any one process is writing to the database,
all other processes are prevented from reading any other part of the
database. For many situations, this is not a problem. Each application
does its database work quickly and moves on, and no lock lasts for
more than a few dozen milliseconds. But there are some applications
that require more concurrency, and those applications may need to seek
a different solution.
EOQ

from http://www.sqlite.org/faq.html#q5

We are aware of no other embedded SQL database engine that supports as
much concurrency as SQLite. SQLite allows multiple processes to have
the database file open at once, and for multiple processes to read the
database at once. When any process wants to write, it must lock the
entire database file for the duration of its update. But that normally
only takes a few milliseconds.

EOQ

so I won't bother if it blocks for fraction of second when I'm doing
commits from more than one application

I bet that would be much faster than elephantine  RDBMS

[Tom Lane]

"Muayyad AlSadi" <alsadi(a)gmail.com&gt; writes:
> > Why not use sqlite? 
>  We tried. Really. It can't handle the concurrent access very
> well, in
>  the best case this means very slow operations, but we've also seen
>  deadlocks and failing transactions. Once that's fixed in sqlite,
>  adjusting Akonadi to use it again instead of MySQL is no problem. 
[ raised eyebrow... ]  mysql's reputation for concurrent performance
is not exactly stellar either.  I grant that table-wide locks are better
than database-wide locks, but unless you have a lot of independently
accessed tables in your DB design, it won't help much.

			regards, tom lane