I got two serveurs. ClientServ and DevServ. The client serveur is on Debian 7 with Mysql 5.5.49-0+deb7u1. My goal is to have the same package in my DevServ.
Unfortunaly, I tried to apt-get install I only got "5.5.55-0+deb7u1". I checked the repo actually there isn't any 5.5.49 package in wheezy...
I tried everything.
Using mysql's .deb, it gives only mysql with the correct version but not the other composents (mysql-server etc).
I saw that in Jessie repo there is a "mysql-server-5.5 5.5.49-0+deb8u1"
Is it possible to use it ?
Please help me... :)
Thank you very much in advance,
Good day
There should be no issues simply downloading all the *.deb packages and installing them for the relevant version of the mysql server. Note that you'd also need to grab the *.deb files for any mysql modules you need at the same time.
Then you just install them directly with dpkg, after first having purged all the installed mysql packages ( apt-get remove --purge mysql* ). Personally however I would not do this, I have never found any significant issue using varying mysql server versions between live and dev machines, and particularly if both are the same version, 5.5, I don't see why you'd experience any significant issues, but if it's actually and critically mandatory to run precisely the same versions, then directly installing the deb files should work fine.
Just make sure to download them and store all the mysql files you'd ever potentially need in a directory somewhere so you have them to install in case the versions you needed go away, or in case you realized you'd forgotten a module or something.
If this is only a dev system, I think personally I'd just install the debs directly to avoid versions changing.
But unless you are absolutely certain some key difference exists between those two debian versions, which probably is not the case, it's probably just some security update or something that has no impact on how mysql server processes sql, I'd just use what is in jesse, and not worry about it.
Sample:
http://mirrors.kernel.org/debian/pool/main/m/mysql-5.5/
There you see versions 47 and 55, for example, of the server, and you'd also grab the 'core' package as well to match. Tnen you'd look for any other modules you might need here:
http://mirrors.kernel.org/debian/pool/main/
keeping in mind that with dpkg, you have to install the dependency first, then the next package, or both together in some cases. However, what I would do first, not last, in your case, is to make sure there actually is a functional difference between the different 5.5 versions before dealing with the potential headaches involved in trying to maintain a server using dpkg deb package installs.
Here's, for example, a list of mysql packages you might need. Note that I just grabbed this off a dev box, this is not intended to be an authoritative list, just an example, but it does show that mysql is used in many different places on a system, and you might run into issues trying to downgrade manually, which is why I'd in general avoid trying this method (for illustration purposes I changed 5.6 to 5.5). The key is to take the absolute minimum package list to download manually the deb files for.
dpkg -l | grep mysql | awk '{print $2}'
libaprutil1-dbd-mysql:i386
libdbd-mysql-perl
libmysqlclient15off
libmysqlclient16
libmysqlclient18:i386
libqt4-sql-mysql:i386
libqt5sql5-mysql:i386
mysql-client-5.5
mysql-client-core-5.5
mysql-common
mysql-server-5.5
mysql-server-core-5.5
php5-mysql
You'd just take the existing mysql install that is working and run that command to see the packages you need to download. As you can see, it's a pain, which is why I'd generally avoid trying to do a development install in this way, I've never hit any sql issues, or return issues using vastly differing mysql versions, so unless your sql queries are using things only found in the specific version, which is very unlikely, you are unlikely to gain much. But this is how you do it in case future searchers land here.
Note that most dev boxes are probably running desktops, and have more mysql dependencies than just the mysql server stuff for web development, and that can lead to issues.
Related
When I configure like shown below and then compile, then the resulting qemu-arm performs many (about 20 to 40) times worse than the qemu-arm-static that came with Ubuntu 18.04.3 (AMD64).
I used the same branch (stable-2.11) as the version that came with Ubuntu.
How could I configure to get more performance?
./configure --static --target-list=arm-softmmu,arm-linux-user --extra-cflags=-O3 --extra-cxxflags=-O3 --extra-ldflags=-O3
I'm not sure if -O3 is a good idea -- you could check whether the Ubuntu package build uses that; I suspect it uses the default -O2 instead. In fact a good first step would be to build the Ubuntu package without any changes (ie get the package source with 'apt source qemu' and build it as an Ubuntu package) and check that it has the same performance you're seeing with the shipped binary version.
If the package you build doesn't have the same performance as the Ubuntu-built binary: then something weird is going on, which you'd need to investigate.
If the package you build does have the same performance as the Ubuntu-built binary (ie better than whatever you're building now): then the difference is somewhere in either how the Ubuntu packaging is configuring QEMU, or in the build environment it is using, or in some set of patches it's using that aren't in the branch you're currently building. You could try to narrow down what the difference is.
Other than that, a general note is that 2.11 is now a pretty old version of QEMU, and there have been performance improvements upstream since 2.11. But they're not 20-40x, so you should definitely try to identify why you're not getting the same performance as the Ubuntu package binary first.
While trying to install Perl modules like JSON::XS or YAML::XS, i receive the same error:
XS.xs:1:10: fatal error: 'EXTERN.h' file not found
I use MacBook, xCode is up to date, everything else that could help is up to date too.
Since OS X El Capitan, Apple introduced System Integrity Protection which restricts writing to /usr/lib /usr/bin and other sensitive directories (even to root or sudo user) that are used by the installation of Perl bundled with the Operating System. This can cause issues when it comes to installing new modules and also if trying to install XS modules ( those linked to external C libraries ).
For this reason you should not consider the default Perl installation as a working development environment, especially if you are installing custom modules.
Check out this thread on PM and others. I had since El-Capitan managed to solve this before by manually building from tarball and adding a few params or environment variables to set the paths believing that it would be best to retain use of the system Perl but this is not the way to go. This makes your environment difficult to build but also brittle and sensitive to OS updates that may either break things in many different ways.
The best practice seems to be starting with a Perl using brew install perl and work in this environment, remembering to setup your bash_profile as directed by the installer.
Also worth remembering to do a brew link perl. If you receive warnings about this clobbering what looks like system Perl libraries don't worry - these are likely modules that were installed by you over the top and it will cause you less trouble to link over these. If you have concerns, make a note of which module installs will be cleared and re-install them once your environment is configured ( ie your module installer approach is configured using cpanm or sticking with the old perl -MCPAN -e shell etc)
This new Perl setup from brew eliminates the need to continuing running sudo which adds another layer of things that can go wrong as environment variables don't follow through and permission conflicts arise etc.
Finally to simplify package/module installation I suggest doing a brew install cpanminus. If you had previously already installed this, you can ensure the paths etc are configured by doing a brew reinstall cpanminus
If you want to take it another step further then you can install perlbrew as well which will give you the ability to run multiple versions of Perl as your user and configure these with their own libs and modules which can be very useful particularly if aligning with your production environment for testing etc.
One problem you may face if moving from system Perl to this kind of approach is needing to deal with any hangovers from installing things with sudo. It wis worth taking a little time to get all this set up right though and your issues going forward will be greatly reduced and you won't be left with that nagging feeling that you don't want to change anything for fear of it all breaking.
I have also come across a Perl Blog Article that suggests a fix for XS issues with perlbrew on Mojave
This Gist described updating your cpan shell install root though this shouldn't be necessary unless your cpan is stuck in an old config after taking steps above.
I've also raised this as a new issue on PerlMonks
After reading https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035624 and installing the Additional headers via
sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
I successfully compiled without the missing 'EXTERN.h' error
In order to follow the common advice I also tried with Perlbrew to install a dedicated development version of Perl. Especially with the advice in mind First, do not use the system Perl on MacOS. The installed version is for Apple, not for you (see the discussion here: https://www.perlmonks.org/?node_id=1224727).
Unfortunately, the following error occurred:
Test Summary Report
-------------------
porting/libperl.t (Wstat: 65280 Tests: 35 Failed: 0)
Non-zero exit status: 255
Parse errors: No plan found in TAP output
Files=2653, Tests=1217766, 708 wallclock secs (52.74 usr 9.40 sys + 395.38 cusr 49.90 csys = 507.42 CPU)
Result: FAIL
make: *** [test_harness] Error 1
##### Brew Failed #####
Therefore, I decided to install it the following way (and not following the advice due to the error).
Even after having the above mentioned macOS SDK headers already installed on Catalina (macOS 10.15.2) it didn't work for me. I faced the issue during the installation of the Perl module Mac-SystemDirectory-0.13. The following steps (by identifying the missing file in hope of having a more generic approach for more or less equivalent issues) did the trick:
Locate the header file (in this case EXTERN.h)
sudo find /Library -type f -name EXTERN.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/EXTERN.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.28/darwin-thread-multi-2level/CORE/EXTERN.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/EXTERN.h
Ensure the installed Perl version (here 5.18) match the header file:
perl -v | grep version
This is perl 5, version 18, subversion 4 (v5.18.4) built for darwin-thread-multi-2level
Export the path for the C-Compiler (note MacOSX10.15.sdk for Catalina and Perl Version 5.18)
export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE
Invoke the Makefile.PL with perl
perl Makefile.PL
BTW — For anybody who's still struggling with this, my workaround was:
bash% module="Sub::Util" # For example
bash% cpanm --configure-args="INC=-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE" "$module"
Please try this
CPATH=$(dirname $(find /usr/local/Cellar/ -name EXTERN.h)) cpan JSON::XS
For Big Sur and perl 5.30, EXTERN.h is at /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Perl/5.30/darwin-thread-multi-2level/CORE
I'm trying to upgrade CPAN itself and got that error. But I have /usr/bin/cpan and I can't write there so I have to tweak it to write the updated version to /usr/local/bin/cpan.
No promises, but yum install perl-devel worked for me.
As #huyz has helpfully pointed out, if you hit this error on a Mac, you don't have this option, even though this is probably your issue, and you need to follow one of the above methods of getting a version of Perl that isn't missing important chunks, as per other answers.
But if, dear reader, you hit this error on a linux host, as I did, then this might be an option for you.
Building on what E Lisse suggested, you might also have luck looking in
/System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/
For example:
CPATH=$(dirname $(find /System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/ -name EXTERN.h)) cpan JSON::XS
You could also find where EXTERN.h is located and add that to your shell by default, e.g. in your .bashrc or .zshrc file:
export CPATH=/System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/
I'm working on a mysql installation script for our system, to be part of an automated deployment system. Looking through previous installations, it seems like we might have been loading redundant packages, some via apt some via pip. Looking at Ansible roles for mysql also reveals slightly differing default package lists (e.g. this and this). So I thought I would look up what these packages actually do---only to find that I couldn't find anything informative.
The definitive list, presumably, is this one from MySQL. However I find descriptions like "MySQL database common files" not very helpful. Common to what?
So my general question: is there a better summary of what the different packages do? And if the answer to that is no, then at least can anybody tell me when/why I would want to explicitly install these packages (which were included in my legacy scripts):
mysql-common
libmysqlclient20
libmysqlclient-dev
and in the case of the last two, why I would install one or both of those, vs simply installing mysql-client (the "meta" client installer)?
I'm trying to install MySQL in my CentOS 6.4 (X86_64) with the command:
"yum install mysql mysql-server"
And I'm having problems with the installation, the error presented is the following:
Check the error log in the following link http://pastie.org/10022423
Any Idea why this error ? thanks for you helps!
The problem is you already have a version of some MySQL packages installed that are from a different distribution/vendor than CentOS.
Since different people created the packages using different names and standards, yum does not know how to fix this situation.
You have libmysqlclient16-5.1.69-1.w6.x86_64 installed already providing the client libraries, but the CentOS package is mysql-libs. This package appears to be provided by "webtatic":
https://webtatic.com/packages/mysql55/
http://rpm.pbone.net/index.php3/stat/4/idpl/21966562/dir//com/libmysqlclient16-5.1.69-1.w6.x86_64.rpm.html
Likely you need to consider removing the libmysqlclient package and installing mysql-libs in it's place. That will probably remove some items because of dependencies, you might be able to get away with manually removing it with the rpm --nodeps -e, but it may also be the packages cannot have their dependency satisfied by mysql-libs so slightly risk move if you don't fully check everything first. This often works, though.
As an alternative looks like you can install the mysql server package from webtatic as well, based on their instructions here, that might be a less complex alternative if you are happy to continue relying on their repository:
https://webtatic.com/packages/mysql55/
As far that I know, that error will shows up when you attempt to install packages that already have been installed before. So, you probably should reinstall your mysql.
Source : https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s3-rpm-conflicting-files.html
I just installed Centos 6.4, and installed MySQL using the version that came with the Centos distribution. To my dismay, it is MySQL 5.1.69 versus the current 5.6.12. As stated on http://dev.mysql.com/doc/refman/5.5/en/linux-installation-native.html, "the MySQL version will often be some way behind the currently available release", but I didn't expect that long.
[root#centosBox ~]# rpm -qa | grep mysql
mysql-5.1.69-1.el6_4.x86_64
mysql-devel-5.1.69-1.el6_4.x86_64
mysql-server-5.1.69-1.el6_4.x86_64
mysql-libs-5.1.69-1.el6_4.x86_64
[root#centosBox ~]# whereis mysql
mysql: /usr/bin/mysql /usr/lib64/mysql /usr/include/mysql /usr/share/mysql /usr/share/man/man1/mysql.1.gz
[root#centosBox ~]#
An alternative is to install by RPM packages which is the "recommended way to install MySQL" per http://dev.mysql.com/doc/refman/5.5/en/linux-installation-rpm.html. I have done so and it wasn't overly complicated, however, I am concerned as I've often been told that I should always install by yum when available. Towards the very end of the documentation, it does describe doing so extremely briefly using yum, however, it is so brief that I question whether it is the way to go.
So.... What is the best way for a not guru Linux user to install/upgrade MySQL on a Centos machine?
Just this week (2013-10-28), MySQL announced official yum repositories for MySQL Community Edition. The packages are intended for use with RHEL-compatible Linux (e.g. CentOS).
All the details including how to set up the yum repo on your system, can be found from the announcement:
http://insidemysql.com/announcing-new-yum-repositories-for-mysql/
A bit off-topic but there we go.
It is recommended to install from the repositories because you can later update your software to a newer version with a simple yum upgrade. The repository takes care of that for you, as well as any dependencies the software may entertain with other libraries.
RPM Packages installed manually (even with yum, which then only acts as an installer) will have to be managed manually as well.
Since the MySQL RPM package shows no dependencies (as far as I can tell from the manual), you are safe from this side.
And to answer your question: the best method is to stick with the versions from the repository. If you need a newer version, then you took the right path.
I am no guru myself but I was happy with the result of the RPM method you mentioned since other times I have seen problems with mysql-libs being a dependency for other packages.
(depending on the 5.6 version you want and cpu)
mkdir MySQL
cd MySQL
wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-5.6.16-1.el6.x86_64.rpm-bundle.tar
tar -xvf MySQL-5.6.16-1.el6.x86_64.rpm-bundle.tar
yum install MySQL*rpm
installs them in the correct order and removes mysql-libs in one step without conflicts.
http://dev.mysql.com/doc/refman/5.6/en/linux-installation-rpm.html
It doesn't surprise me that MySQL is a bit behind. Why would Oracle make it easy for you to not use pay-for Oracle? </rant>
Anyway, you can get the awkwardly named, but otherwise identical MariaDB to run easily by adding a new YUM repository.
You can install MySQL 5.5 (mysql55-server.x86_64) from IUS repository (currently version 5.5.34 available)