From: "Mauricio Fernández" <mfp@...>
Date: 2005-07-22T05:24:17+09:00
Subject: Re: Rubygems now integrated in the FreeBSD ports tree

Thanks for the *quick* reply :)

On Thu, Jul 21, 2005 at 09:23:46PM +0200, Jonathan Weiss wrote:
> > If so, 
> > * Is it possible to apply patches to RubyGems packages? What if the
> >   RubyGems package differs substantially from the pristine sources (e.g.
> >   if there's a complex build process using for instance a Rakefile,
> >   probably with some source code massaging)... wouldn't that case
> >   complicate patching?
> 
> Patching is possible as the .gem file is just an archive. The maintainer
> could specify patches that would be applied to the files inside the gem. At
> the moment there is no routine for extracting the gem and re-archiving it
> with help from the ports system. But it would not be difficult to extend it
> to do it for you.

I see. It'd be necessary to modify the do-install target to patch the
extracted files, right?

> The best way to add patches to the gem is to contact the gem's author and
> the patches should be applied/included in the original software.

Yes, this makes sense anyway in most cases, since we're often dealing with
(potential) upstream patches. And I guess FreeBSD-specific (if any) patches
would be handled as you said. I believe it's still good to be able to patch
at that level because the original author could be MIA, or even disappear
completely after a while.

> Normally patching should only be needed for C-extension gems.

They're often tricky to build, aren't they? :-)

> For a new port you have to create Makefile, distinfo, pkg-descr and
> pkg-plist. 
> 
> The Makefile is not very complicated. Rake's looks like this:
[very clean Makefile]
> MASTER_SITES=   http://rubyforge.org/frs/download.php/4258/
> 
> The pkg-plist can be easily generated automatically with the port
> sysutils/pkg_trackinst. Distinfo is created by doing a `make makesum` in the
> ports directory. 

Would it be possible to point to the original .gem (also specifying the
checksum) instead of putting it under ${PORTSDIR}/distfiles/rubygem/ ?
I don't really know the FreeBSD infrastructure but I suspect the latter
is more costly (?). But I guess it'd require the sort of specific code
you talked about before. Also, is distfiles/rubygem/ updated if one uses
CVSup to track the ports hierarchy? Wouldn't distfiles/rubygem/ become quite
large/heavy eventually?

> When a new release is out, the maintainer has to edit the Makefile, distinfo
> and pkg-plist in order to reflect the new version.
> 
> I worked on an automatic way to extrac pkg-plist from the gem-specification
> but it turned out to be not trivial.

IIRC the metadata includes a complete file list, but it's marshalled with YAML
and inside the "tar(tar + metadata.gz)" .gem structure. Maybe a Ruby script
could handle this ;) (I might try to write it if I find the time).

> > * If the answer to the previous question is affirmative, this means that
> >   newly released RubyGems packages won't be available through the ports system
> >   until a FreeBSD developer generates the pertinent data, right?
> 
> Yes, as with any program avaliable through the ports system. Normally this
> will happen soon after the programs release.

OK

> > * RubyGems packages installed via ports interfere with those installed
> >   directly with  gem install, don't they?
> 
> For the `gem` command they are not distinguishable but this should not harm
> you if you do not try to manipulate the gems installed through the ports
> system with the `gem` command.

I see, so one shouldn't  gem uninstall  anything installed through the ports
system :)

> The idea is that a FreeBSD user should only have to use the ports/package
> system in order to install software. Only one command to manage installed
> software and not `gem` for rubygems `pear` for PHP-Pear extension `perl
> -MCPAN` for Perl libs and so on.
> 
> Just do cd `/usr/ports/my/program && make install clean` or  `portupgrade
> -a` and you are done.
> 
> The system is not perfect but I hope that it helps FreeBSD users.

You're too modest :) It seems to me the system adds:
* atomic installs (although the system cannot yet be protected from
  breakeage through direct invocation of gem)
* native dependencies (like needed typically by C extensions)

These alone (especially the second IMHO) look very well from here :)

I have some concerns regarding upstream source compatibility (the
"require 'rubygems'" and require_gem issues in RubyGems packages
vs. everything else, DATADIR, etc.) and the ability to patch at the
repackager level, but these are intrinsic to RubyGems and not due to
your wrapper.

cheers,

-- 
Mauricio Fernandez