Are binary packages easier?

All my years of experience with various ports systems has led me to the same conclusion that many others had already reached: Don't bother with binary packages from the WEB. Instead, build ports from the source code whenever possible. Binary packages can often be installed more quickly, but the problem is this: Ports are constantly being updated at different times, and binary packages, by necessity, have stricter dependency requirements than the source code.

There are several reasons, but here's one of the biggies: When compiling a program, the compiler verifies that a library function is being called correctly by looking at the source code. In C or C++, this is done by looking at function prototypes, which are usually found in the header files. For example a function that computes an integer power yx might be prototyped as follows: 

    double  power(double y,int x);

This tells the compiler that the function must be given a double and an int every time it is called. If it's given anything different, the compiler will issue an error message and the compilation will stop.

Now imagine that you compile and install the dynamic library that contains this function, and a program that uses it. All is well for the moment. Afterward, you upgrade the library to a newer version, without realizing that the function has been improved to allow non-integer powers, and hence the interface has changed to: 

    double  power(double y,double x);

The program compiled with the old version of the library will no longer work, because it sends the power function an int, but the new version of the function obliviously assumes that the data in that memory location is a double, which has a completely different machine format (and size in most cases).

A binary package installer cannot detect this problem. Instead, binary package installers simply warn the user if any dependent libraries aren't the exact same version that it was built with. Most users become conditioned to ignore these warnings, and eventually end up with an unstable system. In practice, most of these warnings can be safely ignored, but it's only a matter of time before you run into a problem, and it might not be pleasant. You could find that your programs crash, or worse yet, produce incorrect output, which you may only discover much later, and realize you have to redo a week's worth of work.

All programs that call this function must be modified and recompiled before they will work properly. However, if you install the program and the library from separate binary packages, then no compilation occurs, and there is no way to verify that all the function calls in the program are correct.

What I recommend with all ports/packages systems is this:

  1. Start with a clean slate (absolutely no ports/packages installed).
  2. Update your ports tree to the latest snapshot.
  3. Build all your ports from this same snapshot.
  4. When the time comes to upgrade, remove all your ports/packages and go back to step 2.
If you find it necessary to upgrade a single port, and don't want to upgrade everything else, try just updating the framework for that port before updating the whole tree. This way, you won't unknowingly break dependencies for any other ports in your attempt to upgrade.

If you follow this simple advice, all of your programs will be as stable as possible.

If you have multiple workstations, it may be worthwhile building your own binary packages all from the same ports snapshot, in order to speed up distribution within the lab.