I want mySQL 4.1 and portage does not agree.

On my dev machine (which is windows-based), I’ve been running mySQL 4.1.12. I like it. I like the new character encoding that 4.1 brings.

Then I went to send an updated version of the software I’m working on to the live server – which runs an older 4.0.x version. I lost all of the nice latin encodings in there.

So I said, ok. Maybe its time to upgrade to 4.1.

Being a cautious guy, I do it on my non-live gentoo machine. Just to see how it goes.

Turns out portage (the nice easy to use software distribution engine for gentoo) has 4.1 masked. All of it.

Masked? Well, some build flags are saying 4.1.x has not yet been proven stable for x86 processors. It’s not ‘hard mask’ (which would mean it had been proven unstable). It’s just not ‘stable’.

I don’t know how their testing process works, but I figure 4.1 has been there for awhile. There should have been a stable build somwhere. How about 4.1.12 ? Nope. All I can see is 4.1.14, masked for my CPU.

Personnally, I like to run it simple. I don’t like unmasking things. I like stable.

But I really dig mySQL 4.1

So I unmasked it and got it installed (making sure I put up the right flags for getting the cool innodb tables).

Here’s how to unmask things, the safe and portage-friendly way.

In /etc/portage (which you should create if you don’t have it), there’s a file called package.keywords (which you might now want to create, because you most likely don’t have it yet)

In it, you can write rules. So, I wrote one which would enable me to build the version of mySQL I want.

I added the line:
<=dev-db/mysql-4.1.14 ~x86
Which means, “all versions up to and including 4.1.14 of dev-db/mysql with the flag x86 flag means “masked for x86 processors).

When I emerge mysql-ed, I my cool new mysql database.

Neat things : while the stuff was compiling and building, my old mysql was still running and available – no downtime.

In fact, I had to restart the mysql daemon for the engine update to show up. That was pretty neat. Limited downtime is neat.

Less neat thing : I most likely need to update php. It does not like that I switched mysql on it. It keeps telling me weird things like:

Cannot load /usr/lib/apache2/extramodules/libphp4.so into server: libmysqlclient.so.12: cannot open shared object file: No such file or directory

I don’t have a libmysqlclient.so.12. I have a libmysqlclient.so.14. By mod_php really wants libmysqlclient.so.12.

So let’s update.

Turns out all I knew about apache, php and stuff has changed.

Before, I just emerged mod_php and it was neat enough to go and grab me the apache and php it needs (and whatever they need).

Now the packages I knew and used are not ‘it’ anymore. All this stuff is now under dev-lang/php and everything is masked.

Seems like my old dev-php/php doesn’t know how to handle my new sql. I’m lost. I want my mommy.

Well, this is a test box, so let’s test.

I stard by unmerging mod_php and php. Let’s start fresh.

Let’s emerge -v php-lang/php.

Of course, as far as I’m concerned all php packages are masked

  • dev-lang/php-4.4.0 (masked by: ~x86 keyword)
  • dev-lang/php-5.0.4 (masked by: ~x86 keyword)
  • dev-lang/php-4.3.11 (masked by: ~x86 keyword)
  • dev-lang/php-5.0.5 (masked by: package.mask, ~x86 keyword)

So, I unmasked 4.4.0 (that’s the one I want)

Then I got to meet another masked buddy (the gimp?),

  • net-www/apache-2.0.54-r30 (masked by: ~x86 keyword)

Why r30? I’m not really up to date (2.0.52-r1). Portage has 2.0.54-r15 unmasked. It seems swell. Why fuss over the darn r30?

I though about using php 4.3.11 instead. That one wants the masked apache. Great. Well, I’ll unmask it, then.

Looks like apache wants some friends:

  • net-www/gentoo-webroot-default-0.1 (masked by: ~x86 keyword)
  • net-www/gentoo-webroot-default-0.2 (masked by: ~x86 keyword)

What’s that??? Superb package description at gentoo-portage.com:

This is the default Gentoo WebServer content

These version numbers are making me anxious. I don’t think I’d do that upgrade if I were on a production server.

Man, I only wanted to upgrade to mysql 4.1.x!! I didn’t expect it’d need me to install some obscure beta package.

Well, let’s unmask this and see what this one will want me to unmask.

Turns out PHP wants me to unmask some redundants-sounding friends

  • app-admin/eselect-php-0.96.
  • app-admin/eselect-0.9.6

And it seems to be all. Great.

When unmasking, I tend to like to run a tight version control. That’s because I hating unmasking packages. And I don’t want to eventually get a beta mysql5 build without my knowledge. I don’t know if I’m doing this the smartest way.

Here’s what my /etc/portage/package.keywords file looks like now:
@@
<=dev-db/mysql-4.1.14 ~x86
<=dev-lang/php-4.4.0 ~x86
<=app-admin/eselect-php-0.96 ~x86
<=app-admin/eselect-0.9.6 ~x86
<=net-www/apache-2.0.54-r30 ~x86
net-www/gentoo-webroot-default ~x86
@@

I let gentoo-webroot-default run free because, well, I don’t see how it can get any worst. I don’t even see what it is.

I’ll now really start emerge dev-lang/php and see what the new thing look like.

My server (and old 400mhz machine with not enough memory) will probably compile php for a whole day 😛

3 thoughts on “I want mySQL 4.1 and portage does not agree.

  1. Mask? Unmask? Never used gentoo or its package mgr, but this sounds like so much trouble for not much..

    Sheesh.. get the source packages and do it yourself 🙂

  2. Gentoo’s package manager is a very cool thing… it will go get all the required packages, will set itself up in the system, configure the compiling options based on more global, easy-to-uderstand options… All packages are easily gathered and installed from a centralized place.

    It basically does everything I don’t care to learn about the OS, including compatibility checks.

    For example, when I set up my machine, I asked portage (the package manager system) to install “mod_php”.

    It then automatically installed PHP, Apache2 and configured Apache2 to use PHP (none of these things were present on my machine). It configured, compiled and installed the latest stable/tested build of everything I needed to get it operating.

    Greatly reduces the learning curve for me… the little flexibility loss does not weigh much for me.

    It also does a good job of letting everything work together without to much of a hassle when upgrade time comes (most of the things to upgrade I’m not even aware about)

    A rather nifty thing, I think…


  3. (most of the things to upgrade I’m not even aware about)

    That’s always something to worry about 😛 When it stops working you have no idea what was done….

Comments are closed.