Yesterday I hacked together a script that takes a gem file and
builds an rpm out of it. I did it because I manage a pile of
servers and they already have rpm-based auto-update, freshness
checks, and a network-local repository. I didn't want to
reimplement and monitor all of that for gems and to be honest I
don't feel comfortable with multiple package managers running around
lights-out systems.
I think my implementation is cheating a little bit because the RPM
folks go on and on about pristine sources and all and I'm just
starting from the gem. However, the script seemed to build gems for
rake, rails etc and will make my life much easier in administering
said machines.
The script lives here:
http://www.fooplanet.com/projects/gem2rpm/gem2rpm.gz
Some questions/comments for the list:
- Would this approach yield a tool that's useful to anyone but me?
- I couldn't find it anywhere, but does 'gem' scribble in a
manifest or similar when it installs packages?
- Is there a way I can wholesale disable remote upates/queries
short of blowing away the sources gem?
- In order to extract dependency requirement information I did
this:
class Gem::Version::Requirement
attr_reader :requirements
end
I'm not happy with doing this but it seemed like the only way to
go about the getting the version requirements from the gem
metadata without actually parsing the result of as_list.
Is there a better way to do this?
- gem appeared to place the wrapper scripts in different
directories when running with uid = 0 than under another uid. I
don't build rpms as root so this meant that I couldn't get the
wrappers into $RPM_BUILD_ROOT/usr/bin without moving them
myself. Is there a better way to get gem to pretend that an
unusual directory is the root of the filesystem (like make
DESTDIR=foo install usually does)?
- RPM has several fields that GEM doesn't appear to have including
BuildArch, License, and Group. Group appears to be an RPM thing
so I expect it to be missing. Did I overlook some way to
get at the other two?
- I'm unhappy with the contents of the changelog since the rpm
changelog usually reflects the packaging history rather than the
actual package history. Implementing something else seemed like
it would cost more than it was worth. Anyone have any better
ideas?
- Some Linux distributions have an idea of prefixing or suffixing
package names based on the language they come from, usually when
the thing being packaged is a library. For example, Fedora has
names like perl-Compress-Zlib for the Compres::Zlib perl
library. Is anyone aware of such a convention for ruby packages
other than just "ruby-"?
- I couldn't find any easy way of extracting package metadata
concerning rubygems itself prior to having rake installed. Even
then, the data mostly concerned the update package rather than
rubygems proper.
Thanks for your time and any help,
--Gil
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers