On 19/03/10 at 06:44 +0900, John W Higgins wrote:
> Good Afternoon,
> 
> On Thu, Mar 18, 2010 at 1:07 PM, Lucas Nussbaum <lucas / lucas-nussbaum.net>wrote:
> 
> > With ruby libraries:
> > - it is usually difficult to find a usable source. Sometimes we have to
> >  extract the gem and convert it to a tgz. We also have a service
> >  (githubredir.debian.net) that allows us to fetch a specific tag on
> >  github as a .tgz.
> >
> 
> I'm rather confused by this - a gem file (at least as far as I can find)
> contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell
> of the .gem file - what exactly is the issue with that layout? Is there
> something specific that this doesn't provide you that is of great
> importance?

It's just extra work. Also, if I remember correctly, the dates in the
data.tar.gz file are incorrect because of a missing feature in the
pure-ruby tar implementation in rubygems.

> > - then we often have to modify the source, to remove the calls to
> >  "require 'rubygems'"
> >
> 
> I'm pretty sure that's a one liner for 99.9% of cases and I really don't
> think is necessary - you really should look at how Gentoo installs gems
> because we get the benefit of both "manually" installing a package as well
> as full integration within RubyGems (for example gem list --local shows all
> gems installed via portage and well as gem install). If there is no ebuild
> file we can infact turn to emerge-gem to take a gem file and create an
> ebuild (including full dependency checks from the gem itself). Does it work
> every single time - nope - but it seems like a huge improvement over what is
> going on with Debian at the moment.
> 
> > - then we have to find a way to install the files. If the directory
> >  structure uses the setup.rb standard (bin/, lib/, etc...), then it's
> >  easy, and we use our own copy of setup.rb to install everything.
> >  But some libraries don't ship the files in a very organized way.
> 
> Again, you keep seeming to want to continue to take shot after shot at
> developers when clearly it's an issue with the ability of Debian to have any
> flexibility - again looking at Gentoo it somehow, in a very much automated
> fashion, manages to handle all these wild and wacky libraries.
> 
> In fact you might want to look at Gentoo as a way to create sources packages
> because it seems to handle all your issues and will present a nice simple
> tar.bz2 package of the files that might be much easier to work with in
> regards to your need for standardization. And I'm truly not saying that to
> be an idiot or anything - it really seems like Gentoo has solved the issues
> you are having, at least with respect to getting the files into some form of
> a constant layout which may be of great help to you.

I agree that we could have a better infrastructure on the Debian side to
deal with that, and automate many of the tasks. None of the problems are
particularly hard, we just all lack time (and motivation to work on a
somehow poisonous issue).

I really think that, in the end, whether to plug into the gems system
(like Gentoo does) or to leave it for manual installs by the user (like
Debian does) is mainly a matter of taste.

Btw, I see in the github portage tree that former versions for gems are
apparently no longer available. How do you deal with gems that require a
specific (ancient) version of another gem?
-- 
| Lucas Nussbaum
| lucas / lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas / nussbaum.fr             GPG: 1024D/023B3F4F |