# mysql57-server-5.7.24 for i386 searching



## GDI (Dec 11, 2018)

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.


----------



## SirDice (Dec 11, 2018)

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.


----------



## GDI (Dec 11, 2018)

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.


----------



## SirDice (Dec 11, 2018)

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?


----------



## Vull (Dec 11, 2018)

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


----------



## GDI (Dec 11, 2018)

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.


----------



## GDI (Dec 11, 2018)

Vull said:


> For pre-compiled binaries of MySQL have you tried `pkg install` instead of compiling from ports?


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.


----------



## Vull (Dec 11, 2018)

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.


If you still have a working version you can make a new package cache like this:

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


```
tar -xzpf pkgcache.tgz
cd pkgcache
pkg add mysql57-server-5.7.24.txz
```


----------



## Polyatomic (Dec 11, 2018)

Vull said:


> If you still have a working version you can make a new package cache like this: ...


  My lord, a noble solution to the problem you have. Moving forward with this may not be possible for the OP. The reason being:


GDI said:


> We are deleted the Mysql from server by mistake.


`:(`


----------



## ShelLuser (Dec 12, 2018)

Vull said:


> If you still have a working version you can make a new package cache like this:


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


----------



## ShelLuser (Dec 12, 2018)

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.


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 (Dec 12, 2018)

ShelLuser said:


> Although 5.7 is gone


Is it a precise info, 5.7 is ended and won't be continued and/or fixed in ports for 32-bit support?


----------



## ShelLuser (Dec 12, 2018)

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?


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.


----------



## SirDice (Dec 12, 2018)

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.


----------



## GDI (Dec 12, 2018)

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.


----------



## SirDice (Dec 12, 2018)

GDI said:


> But somebody can has already built this version for i386 as it was on our server and He/She has this binary.


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.


----------



## ShelLuser (Dec 12, 2018)

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.


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:

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


----------



## Vull (Dec 12, 2018)

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


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.


----------



## Datapanic (Dec 13, 2018)

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.


----------



## GDI (Dec 13, 2018)

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.


----------



## GDI (Dec 18, 2018)

So, finally we are able to solve this issue. We are able to run the MySQL v5.7.24 (https://freebsd.pkgs.org/10/freebsd-ports-latest-i386/mysql57-server-5.7.24.txz.html) packet from FreeBSD 10.4 on v11 after fix the library dependencies.
Thanks All for your support.


----------



## SirDice (Dec 18, 2018)

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.


----------



## GDI (Dec 20, 2018)

SirDice said:


> 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, we did as you advised, to avoid future headache.


----------

