SLOTed MySQL

llongi · Posted: Tue Feb 28, 2006 2:07 pm Post subject: SLOTed MySQL

Hi all, users and devs alike!

Please take a moment to vote about the future of the MySQL ebuilds on Gentoo.
At the moment work is going on to make dev-db/mysql SLOTed, which means you can install different versions of MySQL on the same system and switch the binaries only between them. But we're not sure if this is worth the effort, both on the devs side (maintainance, getting it to work fully) and the users side (upgrade from normal to SLOTed MySQL), so we're considering dropping the idea of a SLOTed MySQL and return to provide MySQL as it always was provided: a series of ebuilds for all supported versions, and only one can be installed at the same time on a system. We'll anyway maintain improvements like the new init.d scripts and such.
So, please help us in making the decision by voting, if you'd prefer a SLOTed or not MySQL, and if possible, post a comment about why you'd prefer one over the other.
Thanks on behalf of the Gentoo MySQL Herd.
_________________
Best regards, Luca.

BastianBalthazarBux · Retired Dev Joined: 10 Dec 2004 Posts: 78

My vote if for unslotting too, expecially looking at the whole system and not only the MySQL ebuild/eclass

Francesco Riosa,
MySQL herd member

Bad Penguin · Guru Joined: 18 Aug 2004 Posts: 507

I would rather see packages like dev-db/mysql40, dev-db/mysql41, dev-db/mysql50, and so on. They should block one another, doing it this way would allow me to choose when I want to upgrade between major versions.

Running two database servers on the same box is technically senseless in my opinion, so why bother slotting it?

sevenoaksis · n00b Joined: 28 Feb 2006 Posts: 1

My vote is for not SLOTed, especially if SLOTing could slow down availability of new versions at all - that's the number one factor for me.

Kalin · Posted: Tue Feb 28, 2006 4:31 pm Post subject:

No preference as long as it is maintained (as it is now) and SLOTed/unSLOTed does not change from now on.
(Hmm, that means SLOTed after all)

OK, let me rephrase that:

No preference as long as it is maintained (as it is now) and SLOTed/unSLOTed does not change too often (more than once in a year) from now on.

screwloose · Posted: Tue Feb 28, 2006 5:07 pm Post subject:

I work with MySQL everyday and I don't have any use for a slotted MySQL.
_________________
If something can go wrong it probably already has. You just don't know it yet. ~Henry's Modified version of Murphy's Law

Mad Merlin · Veteran Joined: 09 May 2005 Posts: 1155

I'm going to have to go along with the "no" crowd. I don't really see a purpose of running multiple MySQL servers simultaneously. I have been putting off upgrading to the new SLOTed ebuilds, and ideally would prefer to simply stay on the non-SLOTed versions. Again, I think effort would be better spent on keeping in sync with upstream and testing.
_________________
Game! - Where the stick is mightier than the sword!

Jokey_ · Posted: Tue Feb 28, 2006 7:47 pm Post subject:

I agree on the no people.. If it breaks an app, just recompile it

Up to now I didn't find a piece of public available software that needs one special version, so keep up the good work on well tested mysql non-slot builds and we're all happy

_________________
Your ebuild bug is assigned maintainer-wanted? Maintain it yourself in the gentoo user overlay
http://overlays.gentoo.org/proj/sunrise | irc.freenode.net #gentoo-sunrise

GurliGebis · Retired Dev Joined: 08 Aug 2002 Posts: 509

I also go with no.
I see no reason for having more than one mysql server running, it only takes up more memory, and doesn't provide any benefits (as far as I can see, please correct me if I'm wrong).
I would go for the dev-db/mysql40, mysql41, mysql50, to let people choose which version they like, and then have a virtual/mysql that they all three provide.
_________________
Queen Rocks.

robbat2 · Developer Joined: 19 Feb 2003 Posts: 82

I'm against slotted MySQL. I haven't seen any case where it's actually needed. It's a nice idea, but a pointless one.
I'm also against the concept of seperate packages - dev-db/mysql40, mysql41, mysql50 etc - this makes a large mess in the tree as those packages do share files from $FILESDIR. This is exactly what /etc/portage/package.{mask,unmask} is designed for, and it should be used instead of the other weirdness.

wschlich · Posted: Tue Feb 28, 2006 11:56 pm Post subject:

I just upgraded from non-slotted 4.0.20 to slotted 5.0.18 three days ago and it worked fine.
To me it looks like much work has been put into making MySQL slot-aware.
I can imagine that there are uses for parallel installations and runtime uses of different MySQL versions, although I usually have only one.
So I think that if the MySQL maintainers are willing to continue the slot support and provide the same level of user satisfaction as with non-slotted MySQL, I have no objection to keeping it slotted. If there *are* concerns though, I'd prefer to have the maintainers decide on what would be best-supported.
Besides that, I completely agree with robbat2 on how to choose what versions not to use (package.mask/.keywords).
_________________
Wolfram Schlich <wschlich@gentoo.org>
https://github.com/wschlich/ * http://dev.gentoo.org/~wschlich/ * http://wolfram.schlich.org/

tuxp3 · n00b Joined: 28 May 2004 Posts: 61

The only reason slots would be better is so an admin that doesn't pay close enough attention wouldn't get his fingers chopped off when a major mysql version is released, especially one that requires configuration changes. The slots would allow the admin to postpone the upgrade until he switchs over to the newer sloted version.

Other then that.. I doubt production servers would need more then one version of MySQL to be installed, let alone running. So my vote went to NO.

Tux

474 · l33t Joined: 19 Apr 2002 Posts: 714

I'm against. I just can't think of a very compelling reason for it, given that it will probably result in more effort being put into one aspect of maintenance that might perhaps be better spent elsewhere. I'm more interested in seeing existing ebuilds being maintained to a high standard as they seem to vary in quality. For example, mysql-3* is still completely broken on NPTL enabled systems and nothing done in response to a valid (and aged) bug about it. When I looked at that I noticed that the ebuilds had been subject to various improvements through sucessive releases but that these weren't ported back to prior versions.

Actually, one good thing I've noticed (which appears to be related to the slotting work) is the provision of the new mysql/mysql_fx eclasses. I've been obliged to actually try a slotted version due to this bug but now immediately after installing it I noticed that postfix no longer builds with mysql support which is not exactly an auspicious start

I'd say forget about slotting and make sure that all versions currently in the tree are supported to the highest standard possible (or punted if they cannot be), continue the good work on the eclasses to make sure the ebuilds are clean and consistent and to let the sysadmin use package.{mask,unmask} to control the version he/she wants if needs be. Just my 2 pence.

Pin007 · n00b Joined: 23 Mar 2004 Posts: 7

I'm not realy sure. In some specific cases of testing there maybe should be reason for SLOTing.

But what about multislot USE flag like for binutils:

cryos · Retired Dev Joined: 08 Mar 2003 Posts: 242 Location: US

I don't think anything feasible is gained by slotting it, and it has broken at least one box for me with lots of intervention required to fix what was a working box... As far as I could tell you couldn't run two instances of mysql easily either and for most this is not even needed.

j-m · Retired Dev Joined: 31 Oct 2004 Posts: 975

ausmusj1 · Tux's lil' helper Joined: 02 Jan 2004 Posts: 121

I'm in favor of slotting. From a self-employed software developer point of view, you never know what version of what database your next client is going to be using - you also can't afford to upgrade a current installation if you are needing to work with the previous version of the database in order to support a previous client.

However, I can see that most people aren't in this kind of situation, so I'll just live with it if it goes back to non-slot. An idea (that would make more work for the maintainers, true, but would be awfully nice) - either make a mysql-slot package which is the slotted version, or trigger slotting or non-slotting based on a USE flag or some other flag - maybe a MYSQL_OPTS="slot" or something...?

jasperbg · Posted: Wed Mar 01, 2006 9:15 pm Post subject:

I use MySQL in a production environment and am strongly against these slotting changes. They are no use to me and only complicate things unnecessarily.

Having said that, I am also strongly against creating different packages for different versions. That is silly and defeats the whole purpose of portage's masking system etc. If you don't want to upgrade a package, don't upgrade it, or mask it if your fingers can't help typing emerge -DuN world every now and then...

pyreneesjim · n00b Joined: 04 Nov 2003 Posts: 5

I This slotting is a good idea. Having slotting enabled would ease upgrading between major versions as you could run the two versions simultaneously and migrate applications to the new server one by one.

GurliGebis · Retired Dev Joined: 08 Aug 2002 Posts: 509

pyreneesjim · n00b Joined: 04 Nov 2003 Posts: 5

born · n00b Joined: 25 May 2004 Posts: 53 Location: Germany

I would also prefer many packages for different versions which will block each other, if it is possible.

UnSLOTed is the way I would like it to be! :twisted:

behd · Apprentice Joined: 11 Feb 2003 Posts: 155

I voted no because I have no use of multiple sql server on the same computer.

Is there an easy way to install mysql-5.0.18 in an unslotted manner ?
I presume that all the "-500" appended everywhere (directories, binaries, etc...) are due to the fact that it's slotted ? (I mean it's no compilation default of the new release ?)

ie. if I run mysql_fix_privilege_tables-500, I get this
Could not find MySQL command-line client (mysql).
Please use --basedir to specify the directory where MySQL is installed.

NB. As I don't want to bother with symlink, change my other apps default, etc... I would definitively appreciate, if MySQL 5 was installed as the previous versions...

Mad Merlin · Veteran Joined: 09 May 2005 Posts: 1155

behd · Apprentice Joined: 11 Feb 2003 Posts: 155