Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The first problem with these concepts for packaging is that they almost always start with a provably false assumption:

   * that there is a canonical way to build every dependency
With this assumption in hand, they move to a conception in which you somehow make the dependencies available (canonically built) and then assemble your binaries (if not your actual installer) with this.

But there is no canonical way to build lots of dependencies. Two reasons (at least);

   * software libraries with build flags that totally change their behavior. One example that I deal with is libfftw which can be built for single-threaded or multithread use (and the two should not be used in the wrong context). Of course, this can be addressed by referring to each "version" with a different name, but if there are N build flags, that causes an explosion of possible variant names. Another example would include libraries that have hard-coded search paths (this is NOT automatically wrong) that are set at build time; the search paths may differ depending on the target platform. The "appropriate" location for dynamically-loaded modules, for example, differs even among Linux systems, because of the behavior of the system's dynamic linker. Plugins (compiled to dynamically-linked objects, loaded at run time based on user input) are always problematic because they have their own build systems that can be out of sync with those of their associated SDKs.

   * projects that need to patch libraries with changes that, for whatever reason, will not be accepted upstream. An example for me are changes I made to GTK2 to support macOS's version of mouse events so that you can differentiate the extent of a scroll wheel "roll" correctly. My project needs this functionality, and it was never going to be part of GTK2 (the API was frozen before anyone realized that macOS handled scroll wheel events differently). So my project builds with a patched version of GTK2, not the one provided by the platform "package manager"
These sorts of real world complications are easy to want to dismiss or wave away or pretend that there's some sort of magic that will make them vanish and never come back. I don't believe that this is true.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: