 My name is Norval, I'm with the MySQL engineering team. I'm working on MySQL optimizer, mostly with GIS actually. That's not what I'm talking about today. We have a lot of new features. We have JSON document stores. We have generated columns, virtual columns, page compression and partitioning and stuff. And I'm not going to talk about any of that. I'm going to talk about what MySQL 5.7 gives to package maintainers in distros. Not only MySQL package maintainers, I work on the MySQL packaging team myself in Debian, but also to all the applications that use MySQL. So if you use the client library, you can also, there are some changes in MySQL 5.7 that we might want to be aware of. As you might know, 5.7 is not out yet. We haven't finished MySQL 5.7. It's release candidate two, I think. It's still nothing, it's really fixed. So anything I say here, well, it might not end up in the final 5.7, but we're pretty sure it will. So I'm going to start with how we, just to show how we interact with distros, especially Debian, then I'm going to talk about some changes that we actually introduced in Debian with MySQL 5.6 and not 5.7, but MyConf goes through some things we done for system desupport, some changes to the MySQL client library, some security hardening features, and some other changes that we made that you might want to know what. So let's just get started with distros. Or I can just go to this page. This is a faceless company brand thing that you don't know how to contact. This actually has an email address and here is the face. So if you don't know, I'm the single point of contact for package maintainers that want to talk about MySQL servers particularly, but also if you have other MySQL products you want to talk about, just come to me, I'll get you in touch with the right person. I'll be in that for a couple of years now. Before I think, maybe. And I'm kind of answering questions that are directed to MySQL engineering. So if you have some kind of technical issues, I can probably not answer the question, but I can find some people that will answer that question. If it's DIS, I can probably answer. But the point is that I'm in engineering, I'm a developer. I know what technical stuff I'm talking about. I can probably understand your technical question. We also have release engineering people working in distros. We've had a release engineer in Fedora for a couple of years. He's now a co-mentainer of the MySQL service package. We have had a release engineer in Debian as well, but he's kind of leaving Oracle, so we have a new guy coming in. So if you ever meet Lars, he will probably be happy that you know that he's working with Debian and he's trying to get a Debian maintainer status someday. He's real new to that, so it will happen later, not today, but that's kind of the goal we have. We know the MySQL packaging team in Debian is understaffed when it comes to people with upload rights. So that's why we need a maintainer to offload James, who's doing James Page, who's doing most of that work now. My work, since he is trying to get his maintainer status, I try to not actually push fixes and stuff. I want him to do those fixes and push that. So I try to coordinate mostly between distros. So if Debian wants to do something and Red Hat wants to do something else, and there's some Soos guys here, if they want to do something in one way, I can try to contact these package maintainers, try to find a solution that works for all, so that we don't diverge between distros. MySQL and Linux should be MySQL and Linux and not different on each platform, well, unless it has to be because of some choice in its system or whatever. And we also discuss, engage package maintainers when we have important changes coming up. We had some security enhancements that we actually have been allowed to push into stable releases because it doesn't disturb anything that's currently installed and it's so important to enhance security. But mostly we try to avoid making changes in stable releases. We have an agreement with Canonical, which is called the micro-release exception for MySQL, which means that they will take all our patches because they trust our quality assurance. But that means that we really don't want to push too much stuff into stable releases. Actually, the distros, I think Debian is probably the most conservative one that we're dealing with. There's no problem with that. It's just a fact that Debian is more conservative. I think as a user, that's a real good thing as well. So often we will try to clear this with Debian people first. Debian will be first in line because they're usually the most restrictive ones and if they approve it, we can pretty much expect the other ones to approve it as well. That's kind of the way it works, but we're also maybe a bit more embedded into Debian than into other distros. Maybe because I'm Debian, I'm going to use it myself. I use both actually. One of the things we worked out in Debian, Canonical invited all of the MySQL packaging team to London last year, last Christmas. We figured out how to make MySQL on the forks. There's MariaDB and Percona as well in Debian. How to make them all live together without getting too much inter-package dependencies. So we split the configuration file, which is all the forks use the same configuration file as MySQL. There's also the client and service using the same configuration file that makes it even more complicated because there's only one. There's the live MySQL client libraries, only one copy. There's no MariaDB version of that. They have a separate one. So it's really a complicated mix of client and server options with different types of servers. And we finally made a solution to that. It comes in Debian with MySQL 5.6. And it really just creates kind of an alternatives like system for the MyCon file. We also, as MySQL and especially MariaDB are diverging, they're already not fully discompatible, depending on which feature it's using. There are plans in there how to kind of split the data directory so that they don't kind of compete for the same database directory. And then maybe have migration tools if you want to have that. Kind of to the extent that we are able to create migration tools and have resources to do that. I personally think that we might have to split one day because they are diverging. I think MariaDB 10 is do something that MySQL 5.6 can't read and MySQL 5.7 will definitely do something that MariaDB 10 can't read. So there are things we do to the data formats that are not compatible between those two. Percona is pretty much on the same level as MySQL because they just add patches to our source code. But as in 5.6, the real 5.7 stuff, if you notice, Debian has started to package system D. I don't know if anyone, did anyone miss that? This is something we will have to think about as well. We've chosen to, instead of kind of going all native on system D, we can't do that, but we can do that in some systems, but we can't do that for all our running systems. We chose to make system five like demon just make sure that it works exactly the way that system D expects it to. So detaching at the correct point when the socket is ready, when we've done all the, you know, DB recovery and all that stuff, so that system D really understands when MySQL is up and running. But we still have system five in its scripts and it runs as a normal system five detached demon. Before 5.7, you would have run the MySQL D underscore safe thing to actually detach. That's one that detaches MySQL D in 5.6 and earlier doesn't detach. There's a kind of wrapper that detaches for you. And MySQL 5.7 can actually detach and it will log to syslog directly which the wrapper usually is used for in 5.6 and earlier. And we've also created a service file for system D. Currently, it's unchanged. It's the same file in all distros. We have a few CMake options that will generate the file to just give the service name and the location of the PID file, I think. The rest is the same and I really hope we can keep the same one in all distros. That would be a real win for this. Then if you have client applications, this is probably the biggest one for you guys. The other ones are more important to the Paximutane.MySQL server. We are bumping the ABI version to 20. It's 18 in 5.6 but it probably should have been 19. There was a slight ABI break there that we didn't discover. We discovered it's too late to make it into Jesse, actually. That's why there's only MySQL 5.5 and Jesse. But in 5.7, we've skipped the 19 in case we actually needed it in 5.6 but we think that would actually create more problems if we haven't used it. But we bump into 20 and we have limited list of exported symbols. MySQL, actually, until 5.7 has exported all the symbols to the client library which means that it's not easy to link with. If you're linking in some SSL library, for instance, it happens to be the same one as it MySQL is using. It's not a good thing. So in 5.7, it's restricted. We've chosen to restrict it to the documented API. We know people are using more functions in a client library. We've added a few of those but I expect some client applications to fail to compile with the new library. If it does, and you're a package retainer, tell the upstream author and tell us. If it's really needed by the upstream, we can add it in 5.7. You can just add a symbol because the symbol is there in kind of internal in library. We just need to expose it. We can do that in 5.7 stable releases because we're kind of increasing the version number and we're adding stuff, no problem. So we expect there to be maybe a few of those but we've spent a lot of time trying to figure out which symbols we need. That is why we have more than just a publicly documented API. But really applications should stick to the documented API and not go beyond that. But if there's something missing, our goal is to actually add it to the API in a proper way instead of dealing with undocumented symbols. We also coordinate with Fedora and Red Hat so that's from Fedora 21 maybe or and later you can take an application compiled on Fedora and run it on Debian. You couldn't before because we screwed up the symbols file at some point. They discovered that and instead of reporting a bug, they fixed it in their own distribution and it ended up being a different fix than what we did in MySQL. But we've resolved that with Fedora. So now it's from Red Hat 7 and Fedora 21 or something. It's the same symbols. Some things we haven't done is to add package config files in addition to the traditional MySQL config scripts but we're thinking about doing that. If you're using the re-entrant LibMySQL Client Library, please stop doing that. The normal LibMySQL Client Library has been re-entered for many, many years. There's no reason to use the underscore R, it's just a sim link to the normal library. But finally in 5.7 we might remove that. That might cause some applications to fail bit as well. And we have a few security hardening features. Our goal is to be secured by defaults. That means we should have no known attack vectors on default install. Well, what does default install mean? Because the way we do it when you download our source and then run make install is different from what you get when you install in Debian. But it's more or less the same things we'll have to think about. So when we make our install secure, it means that the Debian installation is either more secure or they will not have to patch or run special scripts to make it secure. So in 5.7, the test database that we used to have, it's gone, there are no default grants. You need to add an option to get those if you want to. The root user doesn't have an empty password as default. In Debian, this was never a problem because they've been asked for the password on install. But in Fedora, for instance, it was the install is non-interactive so they can't ask for a password. So now they will get a random password, it's put into a file somewhere, yeah, some trick there. SSL is turned on by defaults. So the client's library will try to use SSL. And we have done some changes that might affect security enhanced Linux or app armor profiles. There are, for instance, the socket file in, well, in Debian, Debian is safe on this point. Debian has used the var run location for socket files for a while, but other distros haven't. They put in with data directory and that means all clients need to get access permissions to that data directory. So that means that some security enhanced Linux profiles and app armor profiles need to be changed. That's one of the consequences. That's actually the hard part of this. We need to change those profiles upstream in those packages. Other, this is just a list of random changes, more or less. But if you're building a server, you might notice that we are actually depending on boost at the moment in 5.7. And we will for the foreseeable future. We use it for GS especially. So I know this very well. And we need one exact boost version. That is because if we upgrade, currently we're on 158, 159 was released on Monday or three Tuesday or whatever. And we don't pass tests if you upgrade. One reason for that is actually a bug in my school 5.7. Another one is that there are floating point numbers in there and it's very sensitive to changing for floating points calculations and the order of calculations. So usually there are a few minor decimals that are just changing on a number here and there in test suite. Which means that our recorded test cases have a slightly different result. But mostly it's possible to build with newer versions of boost. You can usually not build with older versions of boost because we are actively extending boost geometry. We have two engineers full time on extending boost geometry. So we use whatever is the newest when we freeze this. This will be frozen before a stable release and we'll stick to that version for the stable release. That's planned. But if you need to upgrade, we do make the patches because we are continuously upgrading ourselves for the current development branch. So we might adapt the patches but you won't kind of benefit from the QA that we do because we don't do QA with my school 5.7 with newer boosts and what we promise will work. The solution for package maintainers is what we recommend is to build the package from two sources, from the boost tarball and from my school tarball because we're only using header files. We're not using the runtime libraries. Another option of course is to just make sure that the header files from that boost version is in a distro. But I know some distros don't like to have more than one boost version at the same time. So one solution is to just build from two source tarballs. I think that's what we may choose in Debian as well. At least that's the current opinion of the most involved Debian developer at the moment. I'm not a Debian developer. I'm just tagging along. But that seems to be the way to go currently because then we don't introduce new packages. We don't have requirements on other teams to include more boost packages and we won't kind of introduce special MySQL boost header packages that will be misused by other packages. We will add a runtime dependency on MeCab for full text search in Chinese, Japanese, Korean and whatever. You can disable it in the build if you don't want it but that's something you probably want if you wanna be a global and internationalized distribution. It works with the MeCab version in Debian at the moment I think. MeCab is relatively stable on versions so this is not a big problem. We've changed the defaults for some config variables which will no doubt hit some users. Generally we're changing in the, to be more strict than we have been. So strict mode on the defaults and strict mode is stricter. Trying to merge MySQL and SQL in ways. We're trying to move towards standard SQL as much as possible. These extensions have been there for years. Some of them block other standard features so we really try to move to more strict and more formally correct SQL when we can. But we have a lot of users, they are slow to adapt so we need to think about that as well. We also had some spring cleaning in the, actually I think it was a fall cleaning, it hadn't lost fall in removing some legacy utilities. For instance the SQL bench program that was shifting MySQL is gone. We weren't using it, we weren't maintaining it so. Well it's still there if you look at old tar balls you don't need to go to the 5.7 tar ball to get it. So it's GPL you can, I think it's GPL at least otherwise it's some other open source license. But you can get it from somewhere else, we don't need to maintain it in the 5.7 package. We removed most of the Perl dependencies. We're trying to move away from Perl because Perl doesn't run that well on Windows and we are cross-platform to a large degree which meant that we've had to maintain some separate tools for Windows since we have Perl tools and then it's just much easier if we compile things in C++ instead of using Perl scripts. One big change for people that run MySQL manually and install things is that the Perl script that used to be MySQL installed DB is now an option to the servers that's dash dash initialize and it will create system tables and get your MySQL up running for the first time. And then we have some forever ongoing work to be warning free on GCC and Clang. That's our goal. So every time we upgrade our Debian computers our Ubuntu computers, our Fedora, RedEd, whatever. Whatever version of GCC and Clang is in there we will run it, we say, oh no, one more warning, one new warning added in a new GCC version and then we will fix it. We try to always be warning free or if it's pointless to fix it or it's hard to fix it without kind of doing something ugly, we will disable that warning explicitly for that file. But we try to be warning free. We're not warning free on Visual Studio. You probably don't care about that but you should because if one compiler finds something dubious in the code then maybe other users are interested too. So we're trying to get to move towards warning free on Visual Studio as well, no guarantees but we reduce the number of warnings at least. But there's a lot of them. MySQL is mostly developed on GCC. That's what the developers run it on. Some Linux distribution on GCC, that's the normal. Some people are using Clang, we were using Clang for some of the extra tools like Addison, Tyson and stuff but now GCC has them as well. But GCC and Clang are the most important ones for us there. So that was what I had and if you want to know more about what's going on in development, there's the server engineering, developers blog. We have one for release engineering as well. You might find some packaging stuff in there and as always, if you're in doubt, just check the source code. We moved from Bazaar to Git almost a year ago and we're not looking back and we're on GitHub instead of Launchpad where we used to be. Are there any questions? This is not relating to packaging but have you changed the car set for connecting car set? You know it used to be Latin Edna, Swedish, Latin one, Swedish. Yeah, I think it used to be UTF-8 in Debian, didn't it? I know we've been talking about it but I'm not really sure what's currently the default car set. I would have to check. So, but I think the Debian package is using UTF-8. So if you're using Debian, you will have UTF-8 but from upstream sources, I'm not sure. The current MySQL packages are not very friendly to running in a bigger environment where we have multiple databases in the master-slave relationship. If I record correctly, post-inst and other maintainer scripts try to do stuff like repair tables or migrate to newer versions which is not what you usually want. Do you have any plans of following such a mode where the maintainer scripts would do nothing or just skip everything? No. Yeah, so the question was if we're about to, if we have plans in Debian to do something about service that is where you host multiple MySQL instances on one computer, was that the? When you have a large environment with multiple databases in master-slave environment, you don't want, and you upgrade a slave, you don't want the slave to start doing repair tables or migrate to whatever migration stuff that maintainer scripts do. So the maintainer scripts right now, post-inst does various things that you don't want to do on a slave. Yeah, so how can you, are you planning to fix that? Okay, very good question. I haven't heard any explicit plans for doing that. The Debian posts in scripts are doing some, some some operations on your database. Just summarize the question. And if we have any plans to change the packaging, currently no, but that's a real good point and we should talk afterwards. We should really discuss that in a packaging team to figure out what to do. One more question, I think. If there's anyone, okay, then thank you for having me.