4 ms·

Hmm. This is an appropriate implementation for an operating system, but I don't think it's suitable for a programming language. To take Ruby as an example - I

Hmm. This is an appropriate implementation for an operating system, but I don't think it's suitable for a programming language. To take Ruby as an example - I have lots of different interpreter versions installed. 1.8.7, 1.9.3, 2.0, 2.1, jruby, rubinius. There's some scope for managing this in OS package managers, but it's already complex. Then for each of these environments, I want a different set of packages with different versions (some are compatible with older versions, and some aren't, for example). And finally, I want different versions and combinations of these packages for different apps that I might want to run - again, there's limited scope to implement this in an OS package manager.

regularfry 13y ago
You ideally want both. Source packages for development work, and artifacts for deployment. I've switched to .debs for deployment. Oh so simple.
- matthewmacleod 13y ago
  Oh yeah, don't get me wrong - that's lovely. There's nothing more frustrating that trying to get a mildly complex Rails app deployed on a mutable server.
bryanlarsen 13y ago
It's only a problem because the versioning on most ruby gems is broken, because Ruby package managers enable such breakage. The big difference between dpkg and gem is that gem allows you to install more than one version of a gem at a time. With dpkg you overcome this by creating a whole new package when the major version changes. Thus I can install libcap and libcap2 simultaneously. Any breakages in minor version changes are considered significant problems. This is the right thing to do in a production environment: minor & patch level increments are very likely bug fixes and security fixes, and should be applied to all packages that use that library. But it's a PITA for development. And since package manager developers are mostly developers, they did what was right for them, and allowed multiple versions to be installed simultaneously. Today, the right answer is to use something like Vagrant or Docker so that development environments are much closer to production environments.
hapless 13y ago
There are two easy/sane ways to solve your problem. 1. RHEL / CentOS solve this problem with "software collections," aka "scl." Using scl gets you the advantages of ye olde retargetable RPMs but without all the hassle and suffering. Makes it relatively easy to scope your packages that way. 2. fpm doesn't do nearly as bad a job as it used to. Given a gem, it can correctly build it, assign its C dependencies, and assign a prefix so your gems for ruby-ee don't overlap with ruby19 or ruby18.

regularfry 13y ago

You ideally want both. Source packages for development work, and artifacts for deployment. I've switched to .debs for deployment. Oh so simple.

matthewmacleod 13y ago
Oh yeah, don't get me wrong - that's lovely. There's nothing more frustrating that trying to get a mildly complex Rails app deployed on a mutable server.

bryanlarsen 13y ago

It's only a problem because the versioning on most ruby gems is broken, because Ruby package managers enable such breakage. The big difference between dpkg and gem is that gem allows you to install more than one version of a gem at a time. With dpkg you overcome this by creating a whole new package when the major version changes. Thus I can install libcap and libcap2 simultaneously. Any breakages in minor version changes are considered significant problems. This is the right thing to do in a production environment: minor & patch level increments are very likely bug fixes and security fixes, and should be applied to all packages that use that library. But it's a PITA for development. And since package manager developers are mostly developers, they did what was right for them, and allowed multiple versions to be installed simultaneously. Today, the right answer is to use something like Vagrant or Docker so that development environments are much closer to production environments.

hapless 13y ago

There are two easy/sane ways to solve your problem. 1. RHEL / CentOS solve this problem with "software collections," aka "scl." Using scl gets you the advantages of ye olde retargetable RPMs but without all the hassle and suffering. Makes it relatively easy to scope your packages that way. 2. fpm doesn't do nearly as bad a job as it used to. Given a gem, it can correctly build it, assign its C dependencies, and assign a prefix so your gems for ruby-ee don't overlap with ruby19 or ruby18.