Atomicorp

Hi Scott,

I am trying to rpmbuild mysql-5.1.30 for F10 and F8.

No hassles at all, except my F8 server it will break Plesk as plesk there are about 4 packages that have dependencies on with libmysqlclient.so.15

Now as mysql 5.1 uses with libmysqlclient.so.16, what do I need to do to the spec file to build it with both 16 and 15 libraries?

I do have the mysql-5.0.75.tar.gz as well as I am currently running 5.0.75

Then I am in business

Thanks again!

You'd have to build a -compat library to do that, where you'll have client libraries for both mysql 5.0.x and 5.1.x. I did that for mysql 4/5 environments here: http://3es.atomicrocketturtle.com/packa ... lclient14/

Hi Scott,

Ah thank you.

So in my case I only need to build a 15 as that is all that is needed.

I can edit and make a sqlclient15.spec

Last question.

I already built mysql-5.1 so that is alight.

But when I try to yum update it fails as it's missing the 15 compat library.

So when I build this how do I manage to update? Do I first install the sqlclient15 I build and then update mysql?

Or should the mysql-5.1 I rebuild it with dependency on the sqlclient15?

Just want to know the best way to do this.

Thanks again!

Scott,

I made my own mysqlclient15 (I got the spec if you want it), I used remi as he already has one built for 5.0.67. I just tweaked the patches around for 5.0.75

I then installed it.

I then built 5.1.30 and put it on.

Plesk works just great and now I have mysql-5.1

I just used the srpm from rawhide and turned off the testing, as there is an issue building it and then running the tests as root during the build.

So its a success

Yell if you want any files..

Do I need to install the mysqlclient15-devel? Just if I build anything that uses the sqlclient libraries for the time being I want dual support so I could always go back to 5.0.75 if I had to?

PS - On the stopped modsec rules processing error, its still not producing one crash! I got mem-cache back on the last two weeks. I am still convinced its the updated apr, apr-utils and httpd-2.2.11 as a combo.

you'd do the same thing with the compat-devel header files, all you need to do is either make sure they're in the old location, or create a new include and or .a dir. My advice though with -compat stuff is to always use the older -compat library as the first priority. You do this because a lot of other packages will link against that location, and it saves you the trouble of rebuilding a whole mountain of other packages whenever you make an update. Its always easier to tweak an LD_LIBRARY_PATH or something for a newer library than to try to update everything on the box that linked against the old one.

Ancillary to that, in packaging you can have conditions where the upgrade will pull undesired dependencies (or worse, a loop). Especially when you're dealing with other repos, I always strive to avoid conditions that prevent being a "good neighbor".

Thanks Scott, I will kepp that in mind.

I can see the shared libraries are in /usr/lib/mysql

Well at least I confirmed with a mysqlclient15 and mysql-5.1 plesk runs fine.

One other thing I noticed, mysql-5.1 uses now libndbclient.so.3 instead of libndbclient.so.2

However nothing complained about this on my F8 or even F10 box, so I don't think its worthwhile trying to build a -compat for this?

Thanks again!

Hi Scott,

I decided to redo my mysqlclient15.spec

It now also builds a libndbclient.so.2 just to be safe.

It's a nice package as I am using all the latest patches from the 5.0.67 build and applying it to 5.0.75

The libndnclient popped up in Fedora 10 build of mysql-5.0.67-2

I was thinking of just rebuilding the files again still as mysqlclient15-5.0.75-1 and put them into my repo and simply reinstall them to add in the new libraries.

Just I wanted to keep the -1 release.

A good way to verify this would be to go through all the packages that use the mysql 5 client libraries and write a QA script around them, the big ones would be php, perl, and python. What will get you are the tertiary support packages like perl-DBD, or something like mod_auth_mysql in apache. Provided you maintained the identical layout that those packages were linked against, everything should go fine. I have the QA parts set to exit 1 when they run as part of the pre-release script *before* the files go into yum. That way you can keep these from going into your repo automatically (always spend the time to automate something if you can). I can't tell you how many zillions of times this has saved me a lot of grief.

Thanks Scott.

I see you built mysql-5.0.76, where did you get the SQL source I can't find it on the SQL site only .75

I took it from your source rpm and built a mysqlclient15-5.0.76-1 but I had to disable the testing patch for it to build (rpmbuild errors).

I then noticed you not only disabled the testing patch, but the stack patch as well.

My question is why did you disable the stack patch, mine built without disabling it.

I noticed some of your patches are older than mine, my ones are for 5.0.67 a lot of yours still 5.0.40 is that why they failed?

Thanks!

I was given access to the releases dir a few years back