# Using gem to deploy a autoconf packages, expriences?

**URL:** <https://www.ruby-forum.com/t/using-gem-to-deploy-a-autoconf-packages-expriences/139074>\
**Category:** Ruby\
**Created:** [May 30, 2008, 4:45pm UTC](https://www.ruby-forum.com/t/using-gem-to-deploy-a-autoconf-packages-expriences/139074 "2008-05-30T16:45:03Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![olf](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/d07c76/32.png) [@olf](https://www.ruby-forum.com/u/olf)\
**Post date:** [May 30, 2008, 4:45pm UTC](https://www.ruby-forum.com/t/using-gem-to-deploy-a-autoconf-packages-expriences/139074/1 "2008-05-30T16:45:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![olf](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/d07c76/32.png) [@olf](https://www.ruby-forum.com/u/olf)\
**Post date:** [May 30, 2008, 5:58pm UTC](https://www.ruby-forum.com/t/using-gem-to-deploy-a-autoconf-packages-expriences/139074/2 "2008-05-30T17:58:13Z")

</div>

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