Would people use a rubyforge apt-get repository?

J

John Turner

Just an idea that's been bouncing around my head...

Using Ubuntu, there are some ruby libraries that you can download with
apt-get, mostly core ones that aren't included in the ruby package itself.

If rubyforge had a repository that could just be appended to
sources.list and would allow ruby libraries (suitably (re?)named to
avoid conflicts with other apt packages) which would allow downloading
of any libraries on the site(as well as dependencies) it would just be
kind of awesome.

It bugs me a little that I'm installing ruby packages into two different
locations using two different package managers.

John
 
J

James Britt

John said:
...
It bugs me a little that I'm installing ruby packages into two different
locations using two different package managers.


Have you checked the list archives for past discussion on this topic?

It can get heated.
 
T

Trans

John said:
Just an idea that's been bouncing around my head...

Using Ubuntu, there are some ruby libraries that you can download with
apt-get, mostly core ones that aren't included in the ruby package itself.

If rubyforge had a repository that could just be appended to
sources.list and would allow ruby libraries (suitably (re?)named to
avoid conflicts with other apt packages) which would allow downloading
of any libraries on the site(as well as dependencies) it would just be
kind of awesome.

It bugs me a little that I'm installing ruby packages into two different
locations using two different package managers.

I can agree with that. As I've said before, one only has to extend this
to other languages to realize that if this were the status quo we'd
have to deal with dozens of different package mangers. No one really
wants to do that. Which is way an offical package manager is a key
component of any operating systems.

Don't get me wrong. I like Gems! It's a very nice manager (for Ruby
libs). But that doesn't address the issue. Packaging is already
fragmented enough across the variety of operating systems. It's ironic
that in addressing that issue for Ruby the field gets fragmented more.

I've been working on a solution. Something I had called Sow
(http://sow.rubyforge.org) BUT PLEASE NOTE this code is undergoing some
major revision and will likely get a new name. (Release time table is
about a month). So take what's there as merely expiremental at this
point. In anycase, the upshot is this tool transforms packages from one
format to another on the fly and installs them using your native
format. So for instance any .gem can automatically become a .deb.
That's great in itself, but what's really interesting is the side
effect this has. With such a tool in hand it becomes clear that you no
longer even need to package up your source code. Just distribute the
source tar/zip and this tool will make whatever package type you want
out of it transparently upon installation.

While were on the topic of RubyGems, I've actually been considering the
totalliy opposite direction too. Like I said, I really do like Gems. So
I've been wondering, what would it take to make Gems a general purpose
package manager and not just Ruby oriented? Some interesing work has
recently appeared to this end by Matthieu Riou called Raven[1].
Apperaently he's manager to pack Java .jar files into gems. It would be
interesting to see just how generalized RubyGems can become. Could it
ever become the standard package manager of a Linux distribution?

T.

[1] http://raven.rubyforge.org/
 
W

William Crawford

John said:
It bugs me a little that I'm installing ruby packages into two different
locations using two different package managers.

It bugs me, too, but since only debian/ubuntu/etc use apt as their main
repository, adding apt packages only helps split the field further
instead of bringing everyone to a single package manager. IE: You will
always have both gems and apt to worry about, no matter what.

I use Kubuntu, so it's not like I'm a Debian hater or anything. And I
love the apt system. I'd just much rather use Gems for Ruby stuff and
know everyone's on the same page.
 
M

M. Edward (Ed) Borasky

Iain said:
John Turner said something:

One solution would be to use alien:
http://kitenet.net/~joey/code/alien.html
As far as I can tell, all that would be required is for someone to write
an Alien::package::Gem perl file.

iain
People who run Debian or derivatives of Debian might. I guess us
Gentooists would prefer a utility to automate production of ebuilds from
gems, since quite a few gems are already in Portage.
 
D

darren kirby

quoth the M. Edward (Ed) Borasky:
People who run Debian or derivatives of Debian might. I guess us
Gentooists would prefer a utility to automate production of ebuilds from
gems, since quite a few gems are already in Portage.

It would be trivial to do so. Someone took the time to write a gems eclass so
a valid ebuild for a package available via remote gems (using my own as
example) is:

###
<snip header>

inherit ruby gems

DESCRIPTION="A pure Ruby library for reading metadata from Flac files"
HOMEPAGE="http://badcomputer.org/unix/code/flacinfo/"
SRC_URI="http://gems.rubyforge.org/gems/${P}.gem"

LICENSE="Ruby"
SLOT="0"
KEYWORDS="~x86"

IUSE=""
USE_RUBY="ruby18"
DEPEND="virtual/ruby"
###

You could grab the needed info from the gemspec, and you don't need the
USE_RUBY if you are sure the package will run on Ruby 1.6, 1.8 and 1.9.

-d
 
M

M. Edward (Ed) Borasky

darren said:
quoth the M. Edward (Ed) Borasky:


It would be trivial to do so. Someone took the time to write a gems eclass so
a valid ebuild for a package available via remote gems (using my own as
example) is:

###
<snip header>

inherit ruby gems

DESCRIPTION="A pure Ruby library for reading metadata from Flac files"
HOMEPAGE="http://badcomputer.org/unix/code/flacinfo/"
SRC_URI="http://gems.rubyforge.org/gems/${P}.gem"

LICENSE="Ruby"
SLOT="0"
KEYWORDS="~x86"

IUSE=""
USE_RUBY="ruby18"
DEPEND="virtual/ruby"
###

You could grab the needed info from the gemspec, and you don't need the
USE_RUBY if you are sure the package will run on Ruby 1.6, 1.8 and 1.9.

-d
Yeah ... too bad Portage is written in Python, isn't it?

:)
 
D

darren kirby

quoth the M. Edward (Ed) Borasky:
Yeah ... too bad Portage is written in Python, isn't it?

:)

Ahhh, I guess you are talking about something more integrated with portage. I
thought you were talking about a quick script that will write an ebuild from
a gem.

I'm getting curious though and think I may look into this deeper. Looks like
you would have to scan the metadata.gz if you dont have a gemspec.

There is some talk from some of the devs about purging gems from portage and
having a separate utility for installing them like g-cpan for all the Perl
cpan modules...

-d
 
I

Iain D Broadfoot

M. Edward (Ed) Borasky said something:
People who run Debian or derivatives of Debian might. I guess us
Gentooists would prefer a utility to automate production of ebuilds from
gems, since quite a few gems are already in Portage.

Quoting from the page:
"Alien is a program that converts between the rpm, dpkg, stampede slp,
and slackware tgz file formats."

So adding gem support to alien would allow gems to be installed on
debianish, redhattish and slackwarish systems which sounds like quite a
hefty chunk of linux boxes (I'd never heard of stampede before checking
up on alien).

iain
 

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,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top