我有一台 CentOS 6 服务器，正在生产中，实际上托管着几个网站。我现在应该安装基于 Ruby 的 Redmine。remi/ephel 存储库为我提供了 Ruby 1.8.7，但我想使用最新版本 (1.9)。问题是我应该自己编译和安装它，下载源代码和使 gem 工作所需的所有其他开发包，例如用于 mysql2 适配器的 mysql-devel。在生产机器上安装开发包是不是不好的做法？安全性会受到影响吗？我应该坚持使用存储库提供的默认包吗？
答案1
最好留在供应商的包管理系统中。
也就是说，如果您需要某个软件的较新版本，至少尝试使用软件包而不是通过安装make; make build。
对于 Ruby 1.9.3，有人制作了一个 spec 文件：
https://github.com/imeyer/ruby-1.9.3-rpm
您应该能够使用它来为 Ruby 1.9.3 制作 RPM，并以此方式安装。如果没有其他事情，它将使更新更容易（即，rpm -Uhv ruby-1.9.3而不是make; make install）。当然，当更新发布时，您仍然需要负责为自己生成新的 Ruby 1.9 软件包。
一般来说，安装软件有一个偏好等级。
供应商存储库提供的软件。在这种情况下，您将使用友好、友好的管理系统来安装和更新供应商维护的软件包（例如 yum、apt-get）。
通过第三方存储库提供的软件。这里应该有一个小型层次结构，其中有信誉良好的存储库（例如，CentOS 的 EPEL），也有信誉较差的存储库（例如，Ubuntu 上某人的 PPA；我并不是说人们试图通过 PPA 安装木马，而是说这通常是由可能不维护软件包或可能不关注兼容性问题的人提供的）。
通过您自己构建的软件包安装的软件。这就是前面提到的 spec 文件的作用所在。您将把构建过程包装在您的发行版的软件包系统中，这样安装和升级就变得很容易（例如，
rpm -e而不是在 /usr/local 中搜索名称隐秘的文件）。您将在更新出现时承担构建新软件包的责任。不使用包管理安装软件。这是典型的
wget software.tgz ; tar xzvf software.tgz ; cd software ; ./configure ; make ; make install。通常，您会将文件散布到 /usr/local 各处；可能很难获取有关软件的信息（即，您可以简单地运行rpm -q或rpm -ql），并且很难删除。这应该是最后的手段。
我认为 Alex 提到的方法大约是 3。rvm它实际上不在系统包中，但有一个围绕 Ruby 安装的框架。对于 Ruby，在 RVM 上下文中，与该特定 Ruby 相关的 gem 也将通过gem install特定框架进行安装和管理，尽管不是操作系统的包管理系统。
答案2
除非您需要使用更高版本，否则坚持使用“官方”版本通常被认为是一件“好事”。安全补丁已反向移植到官方软件包中，您可以利用软件包管理器的更新和依赖关系解析。
一旦你走出上述境界，事情就会变得相当混乱。
答案3
这只是个人看法，但我从不直接在生产机器上安装源代码包。这会让以后应用安全更新变得更加困难。我担心以后可能会出现问题。
我倾向于尽可能使用内置软件包，并在必要时从外部来源获取其他 RPM。如果我找不到所需的版本，我会在开发机上自己将软件包构建到 RPM 中，然后将该新 RPM 部署到生产中。虽然不优雅，但很实用。
答案4
我总是使用 RVM 来创建和管理 Ruby 环境，RVM 似乎是许多 Ruby 爱好者安装 Ruby 的首选方式。Debian 和 CentOS 维护者提供的软件包跟不上速度。此外，RVM 能够创建与 Python 类似的隔离虚拟环境virtualenv。