4 ms·
Great point, Locke, Thanks for replying. I'll certainly admit that I don't know the gems packaging system as well as I know dpkg and aptitude, but I think that
by e1ven 18y ago
Great point, Locke, Thanks for replying.
I'll certainly admit that I don't know the gems packaging system as well as I know dpkg and aptitude, but I think that that criticism misses the larger issue.
You're certainly right that the gems system could be made to do everything that the Debian/Ubuntu system does, particularly if given time to mature.
But as I pointed out in my post, this wouldn't fix the problem.
Apache, for example, has hundreds of modules, each of which have complex dependencies..
They're released on their own schedule, and they're released across lots of platforms.
Firefox has it's own set of extensions, and updates- You see the same thing with CPAN, and Python modules.
But the more disparate systems you add, the more sets of configurations you need, the more repositories you need, and the more ways to update everything you need.
So for our servers, I could set up a Gems repo, an Apache repo, a System Software Repo, a Cpan repo.
I could have separate upgrade commands for every software package that comes along.
But the complexity is increased with each addition to this system-
* If I want to get a list of everything that's installed under this system, I need to run X commands.
* During installations, I can't chain everything together, I need to run X set of separate installations.
* I need to review X different release chains, to see if there are packages I need to test before deploying to multiple machine
* And yes, I need to learn X different systems for installing software, rather than one system for installing system wide.
There are a lot of good reasons to have the gems system, and I think it's a great tool for individual systems, but for anything that's going farm-wide, It's substantially easier to have everything go through one tool.
- Locke 18y agoI don't know that I particularly disagree with you. The one advantage that a language scoped packaging system has over a system-wide system is developer adoption. Debian, Gentoo, Redhat, FreeBSD, etc all depend on heavily on volunteers to create the packages, manage dependencies, issue security announcements, feed bug reports and patches upstream to developers, etc. I've used Gentoo for a long time and I've watched it struggle in recent years as it loses volunteers. New releases take longer to reach portage, some software never finds its way to portage at all, and I find more and more broken packages. The only Ruby package I install from portage is Ruby itself. The thing is, every Ruby developer uses RubyGems. There are no volunteers because the developers themselves create the packages for each release. I think this is more sustainable, even if I don't think RubyGems is as good as the packaging tools used by the major distributions.
- e1ven 18y agoThat's a really great point, and one I hadn't considered. Of course, in a fantasy ideal world, the way things would work is that the Ruby developers would create their own repository for .debs.. This would mean that if I want the latest and greatest files, I can add their repository to my existing package system, and everything integrates. When I did an "apt-get upgrade" it would check the Ruby repository, and upgrade all my ruby packages, too.. Then, when a package had proven itself to be stable enough, it could be copied back into the standard Ubuntu/Debian repositories, so that everyone could have it, even if they didn't add the repositories. Of course, in the real world, that would be far to much work for the Ruby developers, and would require that they customize for one specific OS.. But a man can dream, can't he? ;)