That's it. I'm done with MacPorts. Fink is the Way To Go (tm).

One year ago or so, I had come to the conclusion that I needed both of them on my machine: Fink was not very up-to-date, but at least it could provide binary packages ready for my Mac. On the other hand, the MacPorts had some bleeding-edge techno that I needed from time to time, but I had to compile everything on my machine which is absolutely ridiculous (have you tried compiling ghc recently ?).

But let's face it. MacPorts maintenance is a nightmare. I think that in one year, I could never reach a fully functional MacPorts installation. Let alone the regular buggy ports which can't even compile, I'm talking about the variant/dependency mess: impossible to upgrade the whole thing because there's always one package that depends on something that conflicts with something else; impossible to remove anything, including obsolete package versions and worse, including inactive ports, because there's always one package that depends on what you want to remove, even if you just want to remove an inactive variant.

For me, the result was an ever-growing installation with duplicate packages everywhere (sometimes, 3 or 4 different and unremovable versions with only one active). Yesterday, I eventually blew my last MacPort fuze when it hanged while deactivating whatever version of aalib, effectively freezing my installation: impossible to upgrade, remove, activate or deactivate anything. I then ended up orgasmatically typing "rm -fr /opt/local/", and you know what ? It felt good !!

Maybe I've missed something from the start. Maybe it goes smoothly for everybody else but me. But this boils down to the same conclusion. If I have to read 3 tons of documentation, semi-obsolete obscure wiki, FAQ, or web forums (oh boy do I hate them) to have the MacPorts behave, the hell with them. I want something that just works.

So here's the thing: Fink is the way to go. As of June 2008, Fink is ready for Leopard and Fink "just works". Yes, you still have to compile things at home, but it's starting to provide binary packages for Leopard already. And what's more, you get the apt/dpkg machinery (for an old Debian user like me, this is cool) because the guys are clever, you know, like, they didn't reinvent the wheel and decided on a package management system that "just works".

Here's my little advice if you want recent free software from the Unix world on your Mac 10.5:

• download the Fink 0.9.0 binary installer and run it.
• run "fink configure" and be sure to tell it to use binary packages if available, and to activate the unstable branch as well.
• run "fink selfupdate" to get the latest point release. That will also let you use the rsync updating method afterwards.
• run "fink selfupdate-rsync" to get bleeding edge stuff. This will also let you switch to the rsync upgrading method by default.

That's it ! Watch it populate your /sw/ directory... If you have Apple's X11 installed, Fink even provides system-xfree86 packages automatically. These are virtual packages for satisfying applications that depend on X11. You don't have anything to do; you can go "fink install gimp" right away.

Ah yes, one last piece of advice: the binary distribution is far from complete, so when you're looking for something, you'd better get used to use fink instead of apt, because you'll get much more information on what's available that way.

Fink about it man, fink about it !

Le logiciel de messagerie d’Orange doit au moins être écrit en Visual Basic sous Windows Vista... voici mon dernier message:

"888" messagerie Orange: le / / à : ce correspondant
a appelé 0 fois sans laisser de message.
------------------------------------------------
De:

Moi je dis qu’il aurait quand même pu laisser son numéro, pour que je puisse le rappeler 0 fois. Il y a des gens qui ne sont pas polis.

So, you know, OOPSLA is a nice conference (it's nicer than ECOOP, by the way). Apart from one thing. Today I was deeply shocked when I discovered that lunch is not included in the conference fee (only people attending tutorials get to eat something).

This is the first time ever that I attend a conference, especially of that size, which doesn't provide sustentation for the attendees. A true scandal, if you ask me.

On the other hand, if the food is what I believe it is, seing the guys coming out of the lunch room, I think I'll consider myself lucky to have to get food by myself...

:-o

With the spreading of revision control systems (CVS, PRCS, Subversion etc) and the benefits of using the autotools for project management and portability, there has been some debate on whether to put automatically generated files in project repositories.

Personally, I've had this argument several times, with different projects leaders (most notably with the BBDB maintainer at the time I upgraded BBDB to autoconf 2.5*). In this article, I'll try to explain why (certain) generated files should go in the repository.

If you're wondering whether such or such generated file should go in your repository, there is a simple rule of thumb:

"what goes in the distribution goes in the repository"

This applies consequently to files generated by the autotools, like the configure script, but not only to them. In the discussion below, I might be speaking of configure in particular, but you should keep in mind that my points apply to many other files.

Some people think that no generated file should go in repositories. They are wrong. If you're not convinced (by my simple rule of thumb), read further, I hope to have you change your mind. I'll give some personal arguments below, and I'll also show how irrelevant arguments that have been thrown at my face are.

Personal arguments

Different kinds of "generated files"

Makefile's are generated at build time, and depend on the user environment. They're very likely to be different from build to build so it is obvious to exclude them from the archive. configure, on the contrary, is the same file for everybody so it makes a lot of sense to have it in the archive. Put it another way, why would you require every single person using the repository to rebuild the same file locally?

Building configure requires autoconf

And this might be a problem in several ways. There is an undeniable fact these days: more and more people give up tarballs and use repositories directly, either to stay on the bleeding edge, or just to simplify the process of getting the latest patchlevel for their stable version of the software. It's easy to realize: just look at sourceforge and other similar hosting services to see how common and popular public repository access has become. And this is normal: if you upgrade frequently, you save a lot of bandwith by downloading only the parts that have changed.

So the current trend is to actually use repositories not only as development facilities, but as a distribution mean as well. In other words, not only developers but also end-users make use of repositories. Given this fact, it becomes obvious that you need to put in the repository exactly what goes in the distribution. The whole point of configure is precisely that once generated, it becomes independant from autoconf. So you don't want to require a working installation of autoconf from each of your users.

Building configure requires the right version of autoconf

The situation is even worse than that: having a working autoconf installation is not sufficient in general. You have to use preferably the same version as the one configure.[in|ac] was written for. For example, upgrading from the 2.14 to the 2.5* series is a major backward incompatible process. Of course, autoconf attempts to maintain compatibility on surface. But remember that it's just a macro package. This means that, almost by nature (the same applies to TeX or LaTeX development BTW), it is nearly impossible to use just the surface of autoconf without having the need to hack something on top of the internals, thus bypassing the standard API. And the internals evolve constantly. That's why in actuality, you often need to follow very closely the version number.

Not distributing configure in the repository thus means that you actually force your users to upgrade their installation of autoconf before upgrading the software they're interested in. And what if they also follow another piece of software that makes use of another version ? How many versions will they be obliged to maintain at the same time?

What I've been retorted

"configure is hudge. It's silly to keep generable files that big in a repository."

OK. The biggest configure script I know of is probably XEmacs's. It's about 500Ko. Most other scripts will probably be smaller. Now, given that we're speaking of a machine large enough to run a revision control system service such as CVS or Subversion, what is exactly the point in trying to save 500Ko?

"configure is hudge. It's silly to download generable files that big at each checkout."

First of all, configure scripts do not change very often compared for example to changes made to the project's sources. And the point of downloading from a revision control system is precisely to download only the things that have changed. So you actually don't download configure at each checkout.

Second, remember that running the complete autotools suite (most of the time, autoconf is not enough. You also need to run automake, aclocal, libtool or whatever through a bootstrap script) takes time. I wouldn't be surprised if on most boxes, the time to download already generated files is actually smaller than the time required to regenerate them.

"I don't want to see those generated files appear in diff outputs"

Abso-fraggin-lutely. And this is not very difficult to achieve: first, it happens only when you do a plain diff, without specifying the involved files. Otherwise, there are plenty of wrappers around diff commands that filter out unwanted files, plus other bells and whistles, and even options for ignoring files in many revision control systems. So this is not a problem in practice.

"Having configure in the repository generates a lot of conflicts."

That's the most frequent argument that I've heard, and it is as irrelevant as the others. If you're just an end-user, you won't ever have to touch configure. Hence, an update of your working copy will just download the delta and apply it. No conflict.

Still, if for some obscure reason, you're getting conflicts, these are not conflicts you want to edit by hand anyway, since the file is generated! So assuming the developers have done their job correctly (meaning: checking in the new configure script as well as configure.[in|ac], actually "fixing" the conflict is as painful as typing rm configure && cvs update. Not much of a burden, is it?

Now, if you are a developer, you might actually get conflicts because of parallel development. But the point is you don't care because this file is generated. What you're interested in is conflicts on configure.[in|ac]. And if you do your job correctly, each tweaking of the source file should lead to regeneration of configure and friends. So the previous paragraph applies here too.



Well, I think that's about it. I hope that you're convinced now. And remember: what goes in the distribution goes in the repository.. It is as simple as that.