From the ebuild: embedded? ( <dev-db/mysql-5.1[embedded,-minimal] ) Stabilization bug of mysql-5.1: http://bugs.gentoo.org/show_bug.cgi?id=321791 Older mysql seems to have vulnerabilities, which are hardly fixable for mysql-5.0
Confirming issue. The amarok-2.3.1.90.ebuild deps also appear inconsistent, given both of these lines: || ( >=dev-db/mysql-5.0.76 =virtual/mysql-5.1 ) embedded? ( <dev-db/mysql-5.1[embedded,-minimal] )
The ebuild isn't inconsistent. The fact is that we haven't been able to port our shared lib patch for mysql to mysql-5.1. We're looking at this again and we'll report back ASAP.
amarok team: please change your DEPs to: embedded? ( <dev-db/mysql-5.1[embedded,-minimal] ) !embedded? ( || ( >=dev-db/mysql-5.0.76 =virtual/mysql-5.1 ) ) Long term, I think that the dynamically linked USE=embedded support may have to be dropped, as porting it to 5.1 has been fraught with failures.
Just one question, what is the real problem with compiling amarok[embedded] against mysql-5.1.50[embedded]? I removed the block in mysql-5.1.50.ebuild, changed my /etc/portage/bashrc to add the -fPIC to CFLAGS, compiled both mysql-5.1.50 and amarok-2.3.1-r1 and both are running ok here. The new amarok read the old database just fine, so what is the real problem?
(In reply to comment #4) > Just one question, what is the real problem with compiling amarok[embedded] > against mysql-5.1.50[embedded]? You're linking statically against it. Look at the size of /usr/lib64/mysql/libmysqld.a and the amarok mysql plugin that gets linked against it. > I removed the block in mysql-5.1.50.ebuild, changed my /etc/portage/bashrc to > add the -fPIC to CFLAGS, compiled both mysql-5.1.50 and amarok-2.3.1-r1 and > both are running ok here. The new amarok read the old database just fine, so > what is the real problem? Nobody wants the amarok plugin to be statically linked against the libmysqld.a, due to the bloat that it causes. My related question to the entire matter: Why do the amarok users NOT want to use mysqld in a non-embedded mode?
(In reply to comment #5) > (In reply to comment #4) > > Just one question, what is the real problem with compiling amarok[embedded] > > against mysql-5.1.50[embedded]? > You're linking statically against it. Look at the size of > /usr/lib64/mysql/libmysqld.a and the amarok mysql plugin that gets linked > against it. Ok, now I get it. You should have explained that in the change log. > > I removed the block in mysql-5.1.50.ebuild, changed my /etc/portage/bashrc to > > add the -fPIC to CFLAGS, compiled both mysql-5.1.50 and amarok-2.3.1-r1 and > > both are running ok here. The new amarok read the old database just fine, so > > what is the real problem? > Nobody wants the amarok plugin to be statically linked against the libmysqld.a, > due to the bloat that it causes. > > My related question to the entire matter: > Why do the amarok users NOT want to use mysqld in a non-embedded mode? > Because there is no documentation on how to setup amarok in non-embedded mode. The link http://amaroklive.com/wiki/MySQL_Server that are in the amarok ebuild is broken.
(In reply to comment #6) > > You're linking statically against it. Look at the size of > > /usr/lib64/mysql/libmysqld.a and the amarok mysql plugin that gets linked > > against it. > Ok, now I get it. You should have explained that in the change log. How big is the plugin and that .a file on your system? > > My related question to the entire matter: > > Why do the amarok users NOT want to use mysqld in a non-embedded mode? > Because there is no documentation on how to setup amarok in non-embedded mode. Why aren't they going the akonadi route? (it runs it's own instance of mysqld for the user, not system-wide, with only exposure via a unix socket). > The link http://amaroklive.com/wiki/MySQL_Server that are in the amarok ebuild > is broken. That links works here?
(In reply to comment #7) > (In reply to comment #6) > > > You're linking statically against it. Look at the size of > > > /usr/lib64/mysql/libmysqld.a and the amarok mysql plugin that gets linked > > > against it. > > Ok, now I get it. You should have explained that in the change log. > How big is the plugin and that .a file on your system? evolucao ~ # du -s /usr/lib64/kde4/amarok_collection-mysqlecollection.so /usr/lib64/mysql/libmysqld.a 8520 /usr/lib64/kde4/amarok_collection-mysqlecollection.so 15152 /usr/lib64/mysql/libmysqld.a That size is not a problem for me. > > > My related question to the entire matter: > > > Why do the amarok users NOT want to use mysqld in a non-embedded mode? > > Because there is no documentation on how to setup amarok in non-embedded mode. > Why aren't they going the akonadi route? (it runs it's own instance of mysqld > for the user, not system-wide, with only exposure via a unix socket). If for every KDE program there would be new mysqld instance then no computer would be able run a KDE session anymore. > > The link http://amaroklive.com/wiki/MySQL_Server that are in the amarok ebuild > > is broken. > That links works here? The link is working now. I think I will change to a different mp3 player.
The memory consumption is going to be identical between mysql-embedded and 1-mysqld-per-program, so you're not gaining anything. I should clarify that akonadi's approach is to have a single mysqld instance per user, so that wouldn't happen.
I am not worried about the memory, as long as there is not another memory leak like the one in plasma-desktop and xorg. I just do not like to setup a whole database just to run a mp3 player full of other problems. I will try another mp3 players. Amarok 2.x is disappointing me since its release, I tried to fix some its bugs, but there is just too many of them.
I would like to add that I too run the embedded version and would really *love* to be able to keep it since I don't want any of that akonadi and extra-mysqld-instances stuff on my system. I also don't mind -fPIC. In short: one more vote that you try your best to keep embedded as an option.
(In reply to comment #5) > My related question to the entire matter: > Why do the amarok users NOT want to use mysqld in a non-embedded mode? > Why amarok users SHOULD want it? If you're developer, and you are using mysql, you may want to use existing server, but for most of users additional running daemon is just a headache. But I think that this bug is not a place to discuss the users wishes. It just about broken functionality. I'm discouraged about Gentoo quality for the last weeks. Firstly broken kernel (bug 333035) was stabilized. Now, new mysql makes a number of packages not compilable (bug 333923) and it corrupts system integrity (this bug). Of course, the security bugs shall have highest importance, but it should not break whole system, right?
(In reply to comment #12) > (In reply to comment #5) > > > My related question to the entire matter: > > Why do the amarok users NOT want to use mysqld in a non-embedded mode? > > > > Why amarok users SHOULD want it? If you're developer, and you are using mysql, > you may want to use existing server, but for most of users additional running > daemon is just a headache. If you want the embedded mysql to be a shared library, you ARE stuck on 5.0.x for now. The original 5.0.x shared-library-embedded took months to get right, and despite more than 6 months work. 02040_all_embedded-library-shared-5.1.39.patch 02040_all_embedded-library-shared-5.1.43.patch 02040_all_embedded-library-shared-5.1.50.patch They fail to compile or link mostly. If you're very skilled with Automake etc, feel free to try and fix. > But I think that this bug is not a place to discuss the users wishes. It just > about broken functionality. > I'm discouraged about Gentoo quality for the last weeks. Firstly broken kernel > (bug 333035) was stabilized. Now, new mysql makes a number of packages not > compilable (bug 333923) Fixed already. > corrupts system integrity (this bug). I don't see ANY data corruption. If such exists in MySQL, please open a new bug for the MySQL team. > Of course, the security bugs shall have highest importance, but it should not > break whole system, right? amarok isn't the entire system.
Where can I download the 02040_all_embedded-library-shared-5.1.50.patch file?
It's in the patch git tree: http://git.overlays.gentoo.org/gitweb/?p=proj/mysql-extras.git;a=summary If you want to use them easily, see the MySQL overlay, 5.1.50-r2 will build with the latest patches (the shared embedded patch is currently excluded, comment out the exclusion in the ebuild to test with it).
And what's the easier solution for me to update my system? I've been unable to update it since the mysql-5.1 stabilization because of amarok dependency on mysql-5.0. I've though about masking mysql-5.1, removing amarok, running a MySQL server (removing the embedded flag in amarok). But none of these solutions make me happy. Any other ideas until this problem is solved?
I secondo comment #3, the first part of comment #12 explains things very well about the need for embedded. I add two points: privacy (I run an encrypted /home) and chance to run amarok on systems I don't administer. I'm sure the latter was a primary concern for the amarok devs. In my opinion the ugly fat static link could be a reasonable, imperfect, temporary solution. Other packages output big warnings about the probable need for a revdep-rebuild, this doesn't look much different to me: "if you run amarok with embedded mysql please rebuild it now to benefit from the new version". Just my 2c :)
I am using mysql statically linked to amarok. The memory problem does not concerns me because I have plenty of RAM memory and even more disc space. The only inconvinient is having to recompile amorak if there is a important fix in mysql, but that does not happen so often so I will keep things this way and continue to teste other mp3 players to see if there is a better alternative. Unfortunately for now all other mp3 players I have tried also had their problems.
Amarok used to allow for an SQLite backend. I think you could even use Postgres. Those were the days... Now it seems like all amarok developers want to do is restrict their player in every way imaginable.
(In reply to comment #19) > Amarok used to allow for an SQLite backend. I think you could even use > Postgres. Those were the days... Now it seems like all amarok developers want > to do is restrict their player in every way imaginable. > You can see their reasons (which I don't share) in the article "MySQL in Amarok 2 - The Reality" (http://amarok.kde.org/blog/archives/812-MySQL-in-Amarok-2-The-Reality.html).
We've made some progress in the linked bug.
Fixed for me with mysql-5.1.51
amarok[embedded] is supported again by using >=dev-db/mysql-5.1.51 or >=dev-db/mariadb-5.1.50. I'm leaving the bug open until we get it fixed for the stable tree.
Seems I pressed the wrong button.
Working for (stable) amarok-2.3.1-r2, too. Please fix the dependencies so that it can use mysql-5.1.51, too
We can't, a stable ebuild can't depend on an unstable one
Ok, I thought this won't be an issue because it could also use a stable version and would only use the unstable one if it was unmasked.
The good news is that mysql-5.1.51 might be marked stable soon.
*** Bug 339020 has been marked as a duplicate of this bug. ***
With mysql-5.1.51 stable, it's time to think about stabilizing amarok-2.3.2-r1 too. It works very well on amd64.
(In reply to comment #30) > With mysql-5.1.51 stable, it's time to think about stabilizing amarok-2.3.2-r1 > too. > It works very well on amd64. I've opened a bug to get it marked stable.
I'm going to close this bug as the only arch left is ppc and they have been lagging for amarok keywords. The stabilization bug will remain open so anyone interested in ppc can follow that bug instead.