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?
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.
Cheers,
Florian
···
--
Florian Ebeling
florian.ebeling@gmail.com
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
···
On Fri, May 30, 2008 at 07:10:59PM +0900, Caspar Florian Ebeling wrote: