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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Rex Dieter wrote:

> Christopher Stone wrote:
>
>> On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter@math.unl.edu> wrote:
>>> Enrico Scholz wrote:
>>> > Do you mean:
>
>
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_runn ing_on_my_system.3F
>>> > ? --> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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@math.unl.edu> wrote:


Enrico Scholz wrote:


Do you mean:



http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_runn ing_on_my_system.3F


? --> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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_MySQL_server_runn ing_on_my_system.3F

? --> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Muayyad AlSadi" <alsadi@gmail.com> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list