2. Is there any documentation of the buildlock system, in particular an explanation of how it works and what was the problem this is supposed to solve? Not one of the problems I had, it seems to me. From reading the sources, I found that there is a no_buildlocks option, and I would prefer this to be the default. There are even traces of a "Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" and the documentation know nothing about.
Martin,
Buildlocks solves several problems.
Fink's dep engine isn't always smart. Suppose foo depends on bar, and bar conflicts/replaces with iggy. If you had bar installed and did 'fink install foo iggy', Fink might build and install first iggy and then foo. Now foo is being built without bar installed, since it's replaced by iggy. If it tries to link to a dylib in both bar and iggy, it will now be linked to iggy but will say 'Depends: bar'. This is BAD.
Building with the wrong packages installed could also happen if the user removes a package while building something that depends on it. Or if the user is running multiple builds at once, one build could remove something needed by the other. The dep engine also gets confused in some other situations.
When these problems occur, usually it results in Fink failing to build a package that really has no bug, or in Fink building a package that's not quite right (like the badly linked library situation discussed above). This causes all kinds of relatively mysterious bugs, and a lot of failed builds that lead to bug reports. We developers don't see it so often because we usually have a lot of packages installed already, but big builds like 'fink install bundle-gnome' on a brand new fink are very likely to run into this problem.
All buildlocks does is while building a package, it installs a "fake" package which depends on everything the current build needs to build. Now, if somebody (a user or fink) tries to remove a package while building something that needs it, they'll get an error. And if a package is about to be built but something it needs is missing, rather than silently try to build and then breaking, the buildlock will fail to install. Then Fink will give the user a message that they should try again (which usually solves the problem), rather than a random build failure that results in an irate message to the mailing list :-)
I'd say that a fair fraction of the error messages that we get on the lists, and the complaints people have about Fink, come from the problems I mentioned above. So it's very important that these situations not happen. And it's not trivial to "just" fix all the little things in the dep engine that can go wrong. Even if the current problems do get fixed, buildlocks will make sure new ones don't come up.
I think it's very important for the sanity of our packagers that buildlocks remain on by default. Essentially the only reason to turn them off is if there's a bug in buildlocks.
Dave
PGP.sig
Description: This is a digitally signed message part
