The misery of Nth Party Packaging Systems

<mood - very annoyed>

I have a beef. It's about the compatibility between various Nth tier packaging systems on any given platform.
When you build a software package, it should just work. A software package to be installed on FreeBSD should not be revealing the developer's personal environment settings, (like trying to look for files on the dev's Apple laptop paths, and spitting out error messages about it.)

This is the strange case of the ruby gem called ZMQ, which is the Ruby interface to the ZeroMQ libraries. It essentially makes ZMQ usable under Ruby.

This is 5th party software.  Third-party software is managed under FreeBSD by the ports collection. The ZMQ libraries install just fine. But you're better off using RVM (Ruby Version Manager) to manage your ivarious installations of Ruby on your system. RVM manages 4th-party software. This is because it one level below a third-party packaging system. The GEM packaging system (Ruby's module installation system) is 5th party software, because it runs under RVM.

FreeBSD->Ports->RVM->GEM
                    3rd      4th        5th

I don't know what second-party software is.

Basically, we have too many packaging systems here on a single platform. They all work fine if you don't try to get them to work together. But everything falls apart when you expect them to interoperate without problems. The GEM installer under RVM under FreeBSD simply cannot figure out where to find the libraries it needs to build GEMS from scratch. It is completely unaware of the location that FreeBSD normally installs libraries, (/usr/local) and so you have to dig through a zillion layers of logfiles and directories to figure out which Ruby module failed, and why, and how to make it work.

This takes away from quality programming time. Seriously. Hours.

What would fix this is some kind of  SAAS RESTful server at FreeBSD that the GEM installer could query, based on the output of uname -a, the gem that's being installed and what package it is looking for. The RESTful server could respond with package meta-data giving installation locations of dependent software for this version of FreeBSD. This would be a cool idea, because people who write GEMs probably don't know the standard locations of installation and library paths for all the possible operating systems out there. Nor do they know which subsystem their package is being installed under.

Such meta-data servers could provide information for literally any OS, including Windows and Linux. Each of these operating systems have unique locations for software installations.

The goal being to rely on standard installation locations for any given platform so you can give people the "IJW" experience (It Just Works - a term coined at Microsoft) when installing stuff.