Paul Brannan
5/30/2008 3:57:00 PM
On Fri, May 30, 2008 at 07:10:59PM +0900, Caspar Florian Ebeling wrote:
> I'm just thinking about how well suited RubyGems might be
> to manage non-Ruby packages, as a quite portable generic
> package manager. So these would be probably autoconf
> style native things which get exclusively used by a ruby
> application layer. With ruby C extensions linking into underlying
> libraries. Has anyone gone this road and maybe wants
> to share some insights on this? Is it more pleasure or more pain?
We use gem to wrap autoconf with rice. To make this work we had to:
- Specify all the autoconf-generated files to be included in the gem
- Set s.extensions = 'configure' so rubygems knows how to build the
package
The main problem for what you want to do is that all gem files get
installed to the ruby gems directory, which in general isn't the desired
behavior for most packages. That is, documentation, libraries, and
binaries don't go in the usual places with rubygems. IMO this works
well for ruby packages, but isn't appropriate for most other software.
> The alternative would be having parts of a complex application
> in some kind of package manager, and our own gems
> silently expecting them to be present, without any control
> over versions and these things. Unfortunately neither ebuild,
> nor debs, rpm, or anything else (at least somewhat) well-known
> works across major POSIX platforms, or even only Linux
> flavors, if I'm not mistaken.
Source rpms are somewhat cross-platform. At least, they can be
converted into debs and probably other package formats.
Iirc slackware packages are nothing more than just tarballs with some
metadata. I don't see how you can get much more cross-platform than
that.
Paul