mysql57-server-5.7.24 for i386 searching

G

GDI

Hi All,

Can anyone provide me the MySQL 5.7.24 server package for i386? On all port storage I can find only x64 versions.
5.7.23 is also accepted.
For FreeBSD 11.2.
Maybe somebody has it in cache?

Please help me.
 
Ports are the same for all versions and all architectures. There are some ports restricted to certain architectures but that's not the case here.
 
It can not be compiled on 32-bit systems due to the bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229605
I need precompiled binary package for 32-bit architecture.

Sorry if I talking something wrong in port/package terms. I'm not familiar with FreeBSD at all. We are deleted the Mysql from server by mistake and can't install it back from port and cant find package for 32-bit CPU.
 
Looking at the errors I suspect nobody is able to build it.

All I can suggest is to migrate to AMD64 (it works fine there). Any particular reason why you must use i386?
 
Might not be what you're looking for but just FYI PostgreSQL works fine on i386. For pre-compiled binaries of MySQL have you tried pkg install instead of compiling from ports? (EDITED: Never mind, I see that particular version isn't available in the packages.)
 
Migration is too hard for us now. And we are searching quick solution. If somebody has installed Mysql 7.5.23 or 7.5.24 on 32-bit and has the package in cache. it will be the good solution for now.
 
Vull said:
For pre-compiled binaries of MySQL have you tried pkg install instead of compiling from ports?
Click to expand...
Yes we tried, but without success. Our cache of packages was deleted by admin a couple of months ago. And we can't find our version online.
 
GDI said:
Yes we tried, but without success. Our cache of packages was deleted by admin a couple of months ago. And we can't find our version online.
Click to expand...
If you still have a working version you can make a new package cache like this:
Code: 
mkdir pkgcache
cd pkgcache
pkg create -a
pkg repo .
cd ..
tar -czpf pkgcache.tgz pkgcache

Then put the pkgcache.tgz file on your new server and...

Code: 
tar -xzpf pkgcache.tgz
cd pkgcache
pkg add mysql57-server-5.7.24.txz
 
Vull said:
If you still have a working version you can make a new package cache like this:
Click to expand...
Why make a whole repository if you're only after one package? That's a waste of effort, just use: pkg create -x mysql, then you'll end up with all the MySQL packages in the current directory. Copy those to the other location and you're done.

Of course there are dependencies to keep in mind; but that's something which pkg info -qdx mysql will be able to sort out. Even if you have to sort them out manually then it'll still be a lot quicker than making a full repository from every installed package (the whole pkg repo is unneeded because you'd end up using pkg add anyway).
 
GDI said:
Can anyone provide me the MySQL 5.7.24 server package for i386? On all port storage I can find only x64 versions.
Click to expand...
Although 5.7 is gone 5.6 still exists: databases/mysql56-server. There's also databases/mysql80-server to consider.

And from what I can tell MySQL can be downgraded.

Worst case scenario: Install 8.0, import your data so it's accessible, export ('dump') it in a universal format, replace 8.0 with 5.6, import your data again and you should be home free. Shouldn't take too long. Still, why not go with 8.0 right away now that you can? It is downwards compatible so all your stuff should continue to work anyway.

You don't have to use 5.7, there are plenty of alternatives at your disposal. For the record: I checked all this using my old (32bit) laptop.
 
GDI said:
Is it a precise info, 5.7 is ended and won't be continued and/or fixed in ports for 32-bit support?
Click to expand...
I can't really answer that because I'm not the port maintainer. I suppose it's possible, but it seems more likely to me that the port will be re-added as soon as they managed to solve that bug which prevents it from building. This is of course assuming that 5.7 is still officially maintained by the MySQL developers.
 
It's not "gone". The port is still there and is still supported (upstream support for 5.7 will end in 2020). The i386 version however has build failures hence there's no package for it. Until the build issues are resolved nobody (including the FreeBSD build clusters) will be able to build and package it.
 
But somebody can has already built this version for i386 as it was on our server and He/She has this binary. And I'm searching such person and asking to make the package with this binary and send it to me.
 
GDI said:
But somebody can has already built this version for i386 as it was on our server and He/She has this binary.
Click to expand...
I'm assuming you don't let strangers build and install things on your servers. So I would ask the person that did it before.
 
GDI said:
But somebody can has already built this version for i386 as it was on our server and He/She has this binary. And I'm searching such person and asking to make the package with this binary and send it to me.
Click to expand...
Sorry to say but that's a useless effort. Other than the involved risks as hinted at by SirDice you're also assuming that the 3rd party used the same FreeBSD version as you have and used somewhat compatible build options. You're also hoping that the package dependencies match.

For example:
Code: 
$ make run-depends-list                                                         
/usr/ports/ftp/curl
/usr/ports/devel/libevent
/usr/ports/archivers/liblz4
/usr/ports/devel/protobuf
/usr/ports/devel/libedit
/usr/ports/databases/mysql57-client
/usr/ports/security/openssl
/usr/ports/lang/perl5.26
If I were to build this version (this is on amd64) you'd end up with a package that depends on a specific version of security/openssl. So if I were to send you the build MySQL package and you happen to use a different OpenSSL version then you'd still end up with an unusable package. And that's only the tip of the iceberg. Notice ftp/curl? That can depend on ports such as security/heimdal which can create even more dependency problems.

This isn't an issue of "just" providing a package.
 
ShelLuser said:
Why make a whole repository if you're only after one package? That's a waste of effort, just use: pkg create -x mysql, then you'll end up with all the MySQL packages in the current directory. Copy those to the other location and you're done.

Of course there are dependencies to keep in mind; but that's something which pkg info -qdx mysql will be able to sort out. Even if you have to sort them out manually then it'll still be a lot quicker than making a full repository from every installed package (the whole pkg repo is unneeded because you'd end up using pkg add anyway).
Click to expand...
Why? ( 1.) Expediency. Biggest system I ever did this for took less than 4 hours, even using a slow i386 system. Don't know how long it would take for me to sort out all the dependencies, lacking as I do your expertise in such matters. My brute-force method might require more machine time, but very little of my personal time, and the machine is still usable for other tasks while the repository is being prepared. ( 2.) Reliability. The pkg create -a method is sure-fire, whereas my ability to do it effectively the way you're suggesting is questionable and, without a lot more studying on my part, unreliable. ( 3.) Feasibility. It's hard for me to work out all the dependencies for a package I have, still harder for a package which I don't have (and in this case, which nobody seems to have). Given all of that, my ability to effectively explain how to do it all in a brief post seems close to impossible.

Thanks for the tip regarding pkg repo, I didn't know that. Even so, that step only takes about a minute, even on a big repo. I love the pkg create command. Every time I use one of these self-prepared repos to duplicate an install, I get some of the time back which I spent preparing it, because I don't have to download everything again. Plus it helps to cut down the load on FreeBSD's busy servers and mirrors, and the pre-prepared packages will still be reliable and consistent for my application, even after the servers and mirrors get updated, or the package gets removed.
 
Why don't you figure out when your repository was deleted by your "admins" and then use svn to get the ports tree from the time/date you lost it all and then rebuild your ancient mysql57-server version from there? I do just that to run certain versions of ports, like www/nextcloud v12.0.5 which was the last revision to support Google Drive...

It can be done.
 
The issue is not in some package deletion, the main issue is in bug which prevent to build the mysql-5.7.24 for i386.
 
I assume by "fixing libraries" you meant making a bunch of bad symlinks? Don't do that, it's going to haunt you later on. If you want/need to run 10.x binaries on a 11.x system install misc/compat10x.
 
  • Thanks
Reactions: GDI
You must log in or register to reply here.
Back
Top