Using gem to deploy a autoconf packages, expriences?

  • Thread starter Caspar Florian Ebeling
  • Start date
C

Caspar Florian Ebeling

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
 
P

Paul Brannan

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,819
Latest member
masterdaster

Latest Threads

Top