Another look at Linux code dependencies

This was in response to my Linux clipboard utilities lead to frustration and defeat.

The following was sent to me in email by someone who prefers to remain anonymous. He explains:

I made some pretty brusque remarks about Mono, C#, and configuration management. C# and Mono aren't terrible, but they aren't compelling and do bring additional problems. RPM package management isn't perfect. However, a lot of the challenge is in creating the spec files. I'm not sure how to approach solving spec file creation issues.

If I was writing for a public forum, I probably would have been a little more politic.

1) A different Linux distribution (as you pointed out) presents no problem. Glipper is actually in Fedora 10's repository

2) Building software that depends on Python bindings to Gnome is a mess in general.

I tried building glipper from the sourceforge tarball, and after adding my one dependency I had no trouble building it. The message from ./configure was a little obtuse, but that's the developer's fault, not Linux or the tools that automate building the configure script.

Once I build software I like to test software before installation. I thought that I would run ./glipper.py from the source directory.

That's when I found out all of the Python module requirements. In true Python fashion, there's no convenient way to test the software before installation. I see this with many Python packages, and I think the casual nature of Python scripting discourages good programming and system hygene. Once I saw the large balls of Python that went along with this program, I decided to skip the installation.

The error message for xclipboard was certainly obtuse. I don't know if xclipboard would run under XCFE. I may try logging in under that window manager later to find out. KDE has its own clipboard manager (Klipper), so that's not an issue.

All in all, my experience was certainly mildly annoying but not show-stopping. I come from a scientific programming, development, systems administration, and systems architecture background so I am not a generic user. One of my areas of interest is configuration / change management. I look at these puzzles as exercises in how not to do dependency management.

Until someone comes up with the C/C++/Python analogue to Maven (Java dependency / build management) or some of the better written Makefile.PL scripts, I think this dependency mess will continue. Someone attempted to do generic dependency management at the package level at Colorado State University a long time ago, but his work never seemed to get much beyond the conceptual / proof of concept stage. I experimented with the tools, but didn't see an obvious way to make them more productive.

BTW - Parcellite (as others have mentioned) seems to be much easier to build, is testable from a user account without installation, and doesn't have all of this Python scripting running about. It's also in the Fedora 10 repository. I downloaded the source code, built it with no problems, and ran it from the command line. The search result for gnome clipboard resulted in Parcellite being the 9th entry. The other two (gnome-clipboard-manager and glipper) seem to not be very active.

Inactivity is one of the warning signs for dependency issues. Having a project at the bleeding edge of technology is another warning sign.

Finally, when confronted with this dependency rat's nest, I find a more measured approach works better.

I once had the joy of getting Mono running on Fedora Core 3. That took the better part of two days chasing down software packages, building, testing, and documenting the results. In the end, I had a complete Mono system up and operational. In the end I also found out that I didn't want Mono. Between the performance issues, SELinux issues, and the perpetual disparity between Mono and .NET, I found no compelling reason to use Mono / C# on Linux.

Have a better 2009.