OpenSolaris EPIC FAIL

I decided I’d be a good sport and try to do some build work for Drizzle on OpenSolaris to make sure we weren’t accidentally Linux-ifying something. Nevermind OpenSolaris installing an nsswitch file set up to not use DNS by default. Nevermind OpenSolaris reinventing the wheel for package management rather than starting with a package management system already in use by people (or and then fixing the things . Nevermind the GPL incompatible CDDL license… I’d be a good sport and give it (another) try.

I should add, in all honesty, I really do want OpenSolaris to be good. I think monocultures are bad, and I think Solaris can be useful in the growth of the ecosystem.

Step one. Install bzr.

pkg search bzr

Nothing. Wasn’t expecting much. That’s ok. Grab tarball. Unpack.

FAIL

Silly me. There is no sudo, so I had become root first (sure – I’m sure there is a better solaris way to accomplish sudo… please provide a sudo command line that accesses the superior solaris tool please?)

tar xvfz bzr.tar.gz

tar: z: unknown function modifier

Must use gtar. Old broken Solaris tar is still default for root user. Pointless. Stupid. Must die.

Ok. Fine. Unpack bzr.

python setup.py build

FAIL

many error messages about ld not working. Something like this:

ld.so.1: ld: fatal: libld.so.4: version `SUNWprivate_4.2′ not found (required by file /usr/bin/ld)

Fine. ld is installed but for some reason doesn’t work.

pkg install SUNWprivate_4.2

FAIL

That’s not a package… After cursing and googling, I finally found this:

pkg install SUNWtoo

THAT certainly makes sense from the error message.

Somewhere in looking for the answer above, I also did:

pkg install gcc-dev

(Notice lovely lack of SUNW prefix) This seems to have installed all of the gcc/automake/autoconf I need. First nice thing… although gcc-dev makes me think it’s going to be files to help me hack on gcc… but I’ll live with it. It’s DEFINITELY the best part of the pkg system so far.

Yay. bzr is installed.

Grab my drizzle tree:

bzr init-repo drizzle
cd drizzle
bzr branch lp:~mordred/drizzle/codestyle

Woot! That works!

cd codestyle
./config/autorun.sh

Woot! That works! Up to date autoconf and automake even! (beating CentOS/RHHEL 5 here… really? autoconf 2.59 and automake 1.9? come on RedHat…)

./configure

Can’t find libevent… that’s ok. It’s a new system.

pkg search libevent

FAIL

silly me. It’s SUNWlibevent. How obvious. (Hint to Sun… the legacy Solaris users are not the target audience you should care about if you want new users here… There are many places where Linux has been eating your lunch for years. Package naming is apparently one of them. Fix it. Change. Grow up. Welcome to 2008 )

pkg install SUNWlibevent
./configure

Can’t find readline. Sigh. That’s less ok. It’s a standard lib guys… oh, wait… hrm. CDDL? Anybody remember why it annoys me?

FAIL FAIL FAIL

There is no readline pacakge.

That’s ok. I’ve been doing this for a while… I know where ftp.gnu.org is. (You know, RMS is right … it IS GNU/Linux that we all run…, with a heavy emphasis on the GNU part.)

Grab readline tarball.

Unpack.

Build.

Install.

Back to drizzle…

./configure

FAIL FAIL FAIL

no ncurses. no ncurses package either.

download. unpack. build. install… (why is there a package manager on this system? )

Back to drizzle.

./configure

no pcre. I can live with that… It’s in SUNWpcre

./configure

FAIL

can’t find pcre.

#$%@%^@

Whoops. Even though OpenSolaris decides to install pcre headers in /usr/include/pcre, which it includes a pkg-config .pc file specifying, pcre doesn’t depend on pkg-config. This is good because…

FAIL FAIL FAIL FAIL FAIL

there is no pkg-config package.

Swear. Curse. Spit. /me punches OpenSolaris in the face.

I KNOW it has to be in there, OpenSolaris is running Gnome after all.

google. read forums. WHERE IS pkg-config??!??1

SUNWgnome-common-devel

Silly me.

pkg install SUNWgnome-common-devel
./configure  # finally works.
make

EPIC FAIL

The final straw for the night… OpenSolaris 2008.05… the most recent release… released this year… 2008… ships with gcc 3.4. From 2004. That gcc 3.4. There is also no gcc4 package. It’s not even old gcc4.0… it’s gcc3.4.

Sigh.

It’s 1AM. I’ve picked on OpenSolaris enough for one night. I’ll give it another go tomorrow.

A good build system is hard to find

I was just reading Jan’s post about how to write a good build system

I’m in the need for a portable, fast build-system.

While I’m not about to write a build system in lua – or anything else, I thought I’d pitch in my thoughts as I’ve been having a similar problem recently. The problem is, autotools is the only system that doesn’t require some prereq to be installed on the system … other than a working build system. The only real downside to autotools (other than needing to learn m4) is that it is useless on Windows.

As Jan says, though, the other systems fall down on the make dist part. This is way important to me, as I also work in my tree alot and I really want to have an automated step to make sure I’m packaging up all the files I need, but not too many. This leads Jan to the inevitable choice of building his own

As a matter of fact here I stand without build-system that meets my needs. My current target is building the MySQL Proxy on Linux, MacOS X and win32.

Throwing lua into the game as a nice side-effect: the scripting language is clean and simple. You can also think about adding the lua-src itself to the build-system to do a full bootstrap in case the user doesn’t have it install

First problem – if the user doesn’t have the build system, and if autotools won’t cut it, then how are they going to build the lua-src.

I’d like to point out that most of this is because Windows is crap. The autotools design goal of not requiring user to install a special build system other than Make is a great one. But because Windows can’t even manage to ship a decent POSIX environment, this is broken. Ever tried sharing source with someone who’s using VisualStudio? Ever get pissed off because there’s no way to have the source figure out where a library dependency is without setting some property in the source by hand?

Anyway – I do think Jan is on to something (as usual) but I don’t think the whole system needs to be rewritten – just autoconf.

Automake runs on the maintainer’s machine, as does autoconf, but the automake output are the Makefile.in files that autoconf replaces stuff in. There’s nothing really broken about this. make, make dist, make distcheck should all still work (ok, except on Windows where they don’t have tar… my sympathy is low) But if you made a program in lua that created something like a configure script that could be run with minimal install requirements on the client (I think needing lua is ok here – as Jan says, it’s easy to install)

That leaves the requirement of producing MSI targets. I think this is a requirement that should be shucked, because it’s not an apples/apples thing. MSI files are the same as RPMs or DEBs. They are packaging, not part of the build, and I think if emitting them is part of the needs, then the build system also needs to be able to make debs. Divorce the work of making MSI files from the build and I think the task is really doable in the short term.

I think that the m4 stuff in autoconf is the only part of autotools that people really get annoyed with. So kill it. Replace it with lua. Or python. Or anything that’s cross platform and low impact. (and by that I do not mean Java – sorry guys, the nightmare that is installing Java environments is a subject of an upcoming rant)

Powered by ScribeFire.

mysql-proxy on ubuntu (and debian)

il corra walks you through building mysql-proxy for ubuntu.

il corra » mysql-proxy on ubuntu 7.04 feisty

First of all, there is not a packetized mysql-proxy for Ubuntu, so the only way to install it is to build it from the source

Which is great. But I’d like to take this opportunity to tell people that I’ve actually been working on packages for debian/ubuntu. They’re almost ready to be released into the wild (I’m waiting on an almost non-related event) If you’d like to play with the packaging stuff before then, check out http://launchpad.net/mysql-proxy

I’ll be sure to let everyone know when the packages themselves are in an APT repository.

Why I hate YUM

I really hate YUM, the crappy-ass apt wanna-be that all the non-Debian distros wet themselves over. Yes, it’s better than what they had before, which was NOTHING. But it is absolutely inexcusable that, when apt was already available, powerful and quick, that they wrote YUM. Not because I think everyone has to use my favorite toy, but because it’s a worse tool. It’s it’s slower, it’s stupid and it gives terrible feedback.

Let’s start with today’s beef. I tried to do this:

yum install libselinux-devel

on a just-installed Fedora 7. What I got was this:

Transaction Check Error:
file /usr/share/man/man8/matchpathcon.8.gz from install of libselinux-2.0.14-4.fc7
conflicts with file from package libselinux-2.0.13-1.fc7
file /usr/share/man/man8/selinux.8.gz from install of libselinux-2.0.14-4.fc7
conflicts with file from package libselinux-2.0.13-1.fc7

Tell anybody what the problem is? First of all, has anyone ever tried installing this package?

It turns out, what it’s trying to do is install the x86_64 and the i386 version of this package, and each one of those packages want to install those manpages. It seems fairly common to me that people might want to install this package on a 64-bit server. Why does it install the 32-bit lib? Why do the packages conflict? And why does the error message suck so bad?

Speaking of terrible error messages. Try this:

yum install kernel-dev

Wait, you might exclaim, being a RedHat person, this isn’t a Debian system, we name our packages -devel. Quite true, my bad. Except what does YUM tell me?

Loading "installonlyn" plugin
Setting up Install Process
Parsing package install arguments
Nothing to do

Hm. Does that mean the package is already installed? Is it up to date? Or do we not even have a package named kernel-dev? Here’s another way to do the same thing:

mtaylor@qualinost:~$ sudo apt-get install kernel-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package kernel-dev

Look at that! E for error, and then it shock tells me what the problem was.

The work has already been done! If you don’t want to use APT, that’s fine, you could at least look and see what it gets right and then improve on it! I mean, that’s the way this whole Free Software thing is supposed to work, isn’t it? Granted, maybe having to specify YUM repositories in chunks of XML is an improvement, and maybe I’m not seeing all the wonderful ways in which this is better than the crappy old APT from Debian.

But I don’t think so.