# SLOTed MySQL

## llongi

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.

----------

## BastianBalthazarBux

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

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

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

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

I work with MySQL everyday and I don't have any use for a slotted MySQL.

----------

## Mad Merlin

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.

----------

## Jokey_

I agree on the no people.. If it breaks an app, just recompile it  :Wink:  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  :Smile: 

----------

## GurliGebis

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.

----------

## robbat2

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

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).

----------

## tuxp3

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

----------

## kerframil

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   :Confused: 

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

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:

```

morcholod / # euse -i multislot

global use flags (searching: multislot)

************************************************************

no matching entries found

local use flags (searching: multislot)

************************************************************

[-    ] multislot (sys-devel/binutils):

Allow for multiple versions of binutils to be emerged at once for same CTARGET

```

----------

## cryos

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

 *robbat2 wrote:*   

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

 

Indeed, there's absolutely no need to split mysql ebuilds version-wise or do similar weird stuff, /etc/portage/package.mask works fine for PHP, Apache and whatever else as well.   :Exclamation: 

This slotted MySQL might be a nice toy for some overlay where people who need it could grab it and work on improving that, and could maybe attract some new maintainers even.   :Laughing: 

----------

## ausmusj1

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

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

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

 *pyreneesjim wrote:*   

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

 

Wouldn't you normally do that on a test server?

----------

## pyreneesjim

 *GurliGebis wrote:*   

> Wouldn't you normally do that on a test server?

 

Ideally yes. But not everyone has the time/hardware to maintain/setup a test server. 

Slotting gives us another way to do this. 

For example with slotting testing a PHP web-app with a new version of MySQL simply involve installing 

the new version of MySQL. Having it listen on another port. Using my most recent backup to set up the

tables on the new server. Then creating a new vhost in apache to test the application. 

I'm not saying that slotting is the best way to do this, it is a useful extra that would be nice to have if 

the cost is not to high in terms of maintenance of the ebuilds.

----------

## born

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 Evil: 

----------

## behd

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

 *behd wrote:*   

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

 

Try masking 5.0.18-r30 and use 5.0.18. That's what I did.

----------

## behd

 *Mad Merlin wrote:*   

> Try masking 5.0.18-r30 and use 5.0.18. That's what I did.

 

well when I looked inside the two ebuild, both seemed to contain code related to slot...

but indeed emerging "=mysql-5.0.18" did the trick... thx MadMerlin 

(btw. nice effort in Game!, almost as good WoW, when do you introduce  the MMO part of your RPG  :Wink:  ?)

----------

## Mad Merlin

 *behd wrote:*   

> (btw. nice effort in Game!, almost as good WoW, when do you introduce  the MMO part of your RPG  ?)

 

Heh, maybe when find more free time... Glad you're enjoying it though.

----------

## SteveYin

I don't think slotted mysql give me much more, I just don't need mysql to be slotted. so, I voted for nonslotted.

----------

## BastianBalthazarBux

https://bugs.gentoo.org/show_bug.cgi?id=125599

deprecation of "Slotted MySQL Upgrade and Migration Guide"

----------

## mmokrejs

Hi,

  I think voting is closed already but I like having multiple versions of mysql on my machine. I don't say the SLOTed solution is the best, actually I never had enough time to study what are those slots for - to install two packages over each other is weird for me. In my eyes mysql SLOTed ebuild installed files into different directories so thats how I would like it to be.  For example, I have in /usr/local extracted about 5 different versions of mysql official binaries, like mysql-standard-5.0.15-linux-i686-glibc23.tar.gz. The "upgrade" for e always meant to unpack them, symlink /usr/local/mysql to say /usr/local/mysql-standard-5.0.15-linux-i686-glibc23 and make sure I start mysqld by

# cd /usr/local/mysqd

# bin/safe_mysqld ....

That's the official way how to start it. One even did not have to edit the /etc/my.cnf file. This has always worked. When reporting bugs in mysql, one is asked to use official mysql binaries because mysql people select and sometimes employ their own fixes to libc, mostly because of threads. So, the best way to use mysql in production was to use their binaries. Even better, they provide icc generated binaries, something what is still not available on Gentoo.

Why I need multiple versions? For example, I had to test large packet support in mysql and had to re-link many times mysql-python against different libs to show when the bug was introduced. Further, I use flatfile dumps of my tables for backup purposes in cvs repository. I don't like the fast, multi-line INSERT statemnts syntax produced by mysqldump-5. Although there are compatibility flags to tweak the format of output I never managed to get exactly same output as with mysqldump-3 or 4. So, I just call /usr/local/bin/mysql-*-4.0.24*/bin/mysqldump ....

For migration of the data, it is very easy to start another mysql daemon on another port  and test your application. What I think would be a problem with current SLOTted installation is that /etc/mysql points to /etc/mysql-500, etc. I think the SLOTted idea was wrong in the way that we should really have /usr/mysql-standard-5.0.15-linux-i686-glibc23/(etc|bin|lib|include|man) with its whole structure _as distributed by MySQL_ in their tar.gz files and just fiddle with PATH and LD_LIBRARY_PATH to execute this or that version or compile against this or that version. The datadir should be expected in /usr/mysql-standard-5.0.15-linux-i686-glibc23/data and left to the user to decide if it will be a softlink to /var/lib/mysql-blah or not. That's because it is sometimes not necessary to migrate the data and you won't be able to figure out in advance what magic emerge shoudl perform. Probably some env variable would suffice to tell emerge against what to compile (and pickup one of those many /usr/mysql-* versions, I think user would supply dirname). That's what I would strongly appreciate. I don't have to re-install my "default" installation, I just want certain application to be linked, say statically against yet another version of mysql. And, I want to fire-up another mysql instance on another port. That's all what I would expect from "SLOTted" version.

In summary, although I don't know exactly how SLOTs work (sorry for my ignorance) I was happy in this particular case those different versions of mysql were in separate directories. I understand the soflinks were necessary and I was perfectly with that. It was a pitty one couldn't link against any specific version of mysql. Yes, I would need ways to link either against mysql-standard-5.0.15-linux-i686-glibc23 or mysql-standard-5.0.18-linux-i686-glibc23, etc. Thus I think mysql-500 slot would accomodate only one version mysql-5 for me, which didn't suffice for me. So, for me it was also more an inconvenience to have this SLOTted thing break my working installation but still I thought it will improve.

If I could express my advice, focus on ebuild to provide static mysql binaries using binaries from mysql site. The speedup of almost 30% with icc generated binaries is much more of interest to me. Moreover, one can be sure things are well tested, binaries can be even static and then one can be sure some libc update won't break thread support in mysql. Provide one mysql ebuild which installs into /usr prefix but provide additional way to install into /usr/mysql-(static|dynamic)-x.x.x-whatever for those who need more. And provide measure how to compile certain apps in portage against of of those extra versions. This won't break anything for most users having only single version and developers will be happy with the infrastructure.

Finally, thanks to everybody who worked on this, I think it was worth the effort, although I have always reccommended in my bugzilla responses to allow multiple binary version from official MySQL website instead. Time to go for bug #83424. Thanks to you everybody!

----------

## Raptor911

i was really excited when i moved to SLOTed

but after reading all of the 'no' votes i can too see that is it not really needed But kicked ass to allow my to dev/test everything on my laptop

----------

## vicaya

Slotted version of mysql is only mildly interesting for software dev/qa, who should really use vmware or uml etc to simulate multiple production environments. I use mysql in production. Slotting mysql is a waste of time.

No.

----------

## jkroon

Sorry, but some versions of MySQL does behave differently.  As an ISP I'm very damn interrested in running multiple versions of MySQL on the same machine.  Some clients does complain that their (most of the time) incorrectly written applications doesn't work against MySQL version 5.0.x.

*sigh*, and least I never pushed the SLOTs to production, guess it's time to go clean up the test servers...

Thanks to everyone that put work into the SLOTing.  It was a tad weird initially but imho well worth the effort.

----------

## BastianBalthazarBux

Thanks to Stuart hosting it's avaiable again

Browse:

$ http://svn.gnqs.org/projects/gentoo-mysql-overlay/browser/slotted

Checkout:

$ svn co http://svn.gnqs.org/svn/gentoo-mysql-overlay/slotted slotted

I did not have the time to test it, and in the near future I will also be rather busy.

----------

## jkroon

Thanks.  Not ideal as in it's a manual svn up every time when you emerge sync, but since that is scripted as well I suppose it's acceptable.

Much appreciated.

----------

## jonnevers

 *CHTEKK wrote:*   

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

 

I've run mysql for at least the past 4 years straight. and I absolutely and utterly vote NO to slotted mysql. The slotted 5.x series causes more problems and I can't see it solving anything. Right now I moved my server back to the 4.x series because the slotted 5.x was a headache.

for instance, right now on a client machine:

```
host username # emerge -Cpv mysql

>>> These are the packages that I would unmerge:

 dev-db/mysql

    selected: 5.0.19 5.0.18-r30

   protected: none

     omitted: none
```

I have two 5.x versions installed. For a package such as mysql this dosen't make much sense to me and requires that I actively take an additional step to remove the older package. The only reason I can see to want this sort of behavior is testing db applications but really if you are doing code testing against different versions of mysql you might as well as install them manually into sandbox environments and perhaps only share a common database directory. just my two cents.

- Jon

----------

## jkroon

From a client-lib point of view I can understand you're viewpoint.  You should consider, however, that the daemons do act a little different in some suttle ways.

Whilst I'm mostly satisfied with having only a single version of MySQL every now and again there crops up a silly situation where I'd like both.

Slotting should be restricted to one version of MySQL 4.0.x, one of 4.1.x and one of 5.0.x imho.  But I can also see that having multiple versions of MySQL can cause problems.  So I'm not too picky either way, I suppose I should be running 2 seperate production DB servers in any case to make 100 % sure that the different versions don't step on each others toes.

----------

## ew

 *jkroon wrote:*   

> As an ISP I'm very damn interrested in running multiple versions of MySQL on the same machine.

 

ACK. We need a slotted MySQL for the same reason too.

----------

## jonnevers

 *ew wrote:*   

>  *jkroon wrote:*   As an ISP I'm very damn interrested in running multiple versions of MySQL on the same machine. 
> 
> ACK. We need a slotted MySQL for the same reason too.

 

from my experience, in this case I'd personally rather manage the installations manually. I mean you could use this justification to SLOT every package that is in portage. "we need package 1.x and package 2.x for testing".

can SLOTTING be turned off completely? mysql is not the only SLOTTED package that I think makes portage maintainance more difficult. I haven't found anything in the documentation specifing how to disable this feature.

- Jon

----------

## ew

 *jonnevers wrote:*   

> I mean you could use this justification to SLOT every package that is in portage. "we need package 1.x and package 2.x for testing".

 

But I'm not talking about every package.  :Very Happy:  I'm talking about packages with ("rapidly") changing APIs:Apache 1/2

MySQL 3/4/5

php 4/5

----------

## jkroon

Ag lets face it.  ISPs has some ... unique requirements and wishes.

And SLOTing has a few disadvantages (like the whole need for eselect, gcc afaik can only have a "global" select, not a per-user one).  For services - how do you decide which one to start?  When you invoke mysql from the command line, to which daemon should it connect?

So yes, all in all I can see many problems and I can very well understand why you do not want it SLOTed for the most cases.  It would be very nice if one could (like USE flags, or keywords) enable/disable the SLOT feature on a per-package bases, but this again is yet another variable that will impact on portage.  A system which I consider far superior to rpm, and probably apt as well (It's been a while since I used apt but it is, from what I do recall, the best binary package manager I've yet seen).

In the end, one way or the other will work for me.  Will just have to work a bit harder to help clients to make their apps work with whatever version of MySQL I coose to run.  Or use a second server.

----------

## llongi

SLOTed MySQL was not removed from the Portage tree since almost two weeks and it's not coming back soon (if ever).

If you really need it to use it on testing systems, then grab it from the MySQL Overlay, the slotted/ branch is what you're searching for.

----------

## mdshort

I believe it should remain slotted, and I also think that apache should be slotted too.

I can't remember how many times I've needed to install more than one version of apache, such as a stripped version and a full version, or maybe be able to modify the sources of one. (for use with pass-through techniques)

----------

## apoorvkhurasia

 *CHTEKK wrote:*   

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

 

Please help me with this term "switch the binaries only". I am not aware of what this means, even though I have been using mysql for quite a long time now on gentoo. Thanks for any help in advance.

----------

## llongi

 *apoorvkhurasia wrote:*   

> Please help me with this term "switch the binaries only". I am not aware of what this means, even though I have been using mysql for quite a long time now on gentoo. Thanks for any help in advance.

 

That basically meant that you could switch which version the main /usr/bin/mysql binary was linked to. You for example would have had /usr/bin/mysql-400 and /usr/bin/mysql-500, and could easily choose what the main /usr/bin/mysql linked to (as it was a symlink). But that's not important anymore, there is no more slotted MySQL in the tree, as it was decided.

----------

## smiffy

Smiffy say no.  In the unlikely event that I would want to use an older (4.x) version of MySQL, it would only be to test something, so I would run it on another box.

BTW - is there supposed to be a vote button or something?  (Inveterate mailing list user who has never got the hang of web fora.)

----------

## net.gholam

Am I correct in thinking that the slots were more specific than 3, 4 and 5? like 5.0.18 and 5.0.17.

It was my understanding that slots were intended to allow mutiple feature complete releases of projects to be installed side by side. The classic being version 1 and version 2. They generally are quite different and quite often both are needed unless you work in a very limited sphere.

In which case I would vote no to slotting mysql too. However having a version 3, 4 and a 5 can be quite handy. I am a contractor and do lots of contracts for different projects and also use and work on a number of open source projects. Each having different requirements at the moment i have some projects i'm tinkering with that use mysql 4 and some mysql 5.... I also wanted tonight to check out some performance metrics of the different version not the same hardware...... hence my being here and very dissapointed

my 2c, ill check out the overlay

----------

## jonnevers

I think this can be unstickied....

----------

