Package requests for the prelim. Ruby Production Archive

[Mauricio Fernández]

As of today, 110 libraries/applications are available in
the prelim. repository of the Ruby Production Archive (see
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packaged_Software); I have
packaged all the "top-sellers" in Rubyforge and several lesser-known
programs.

I need your help to prioritize the remaining sw., and would hence
appreciate some feedback:
(1) which lib/app would you like to see packaged?
(2) do you want binaries? If so, for which platform (I expect win32 to be
the predominant answer, plz specify which runtime/"Ruby distro")

You can place your answer to (1) in
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Package_Requests

thx

 

[Dave Thomas]

As of today, 110 libraries/applications are available in
the prelim. repository of the Ruby Production Archive (see
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packaged_Software); I have
packaged all the "top-sellers" in Rubyforge and several lesser-known
programs.

You should probably remove RDoc, as it is bundled with Ruby. Installing
a parallel version will confuse things, and may well break existing
documentation.


Cheers

Dave

 

[Mauricio Fernández]

You should probably remove RDoc, as it is bundled with Ruby. Installing
a parallel version will confuse things, and may well break existing
documentation.

That (breakage) won't happen

The package is misnamed. I should have called it ri-rpa-support;
it is not a complete rdoc, just provides support for ri-rpa, and can
coexist with the normal rdoc. At any rate, were it to conflict with
the normal one (which won't happen cause it's installed under rpa-rdoc/
in sitelibdir), rpa-base would detect the conflict and prevent it.

Regarding ri-rpa, I distribute it as a separate ri with some RPA-specific
patches because I didn't want to force you to change anything in the
one shipped with Ruby only to make things easier for RPA/rpa-base
(*). No harm is done though because it operates independently from
the standard one -- that's why I was redistributing parts of the rdoc
'runtime' to make it work.

Now, I hear the standard ri will be modified because otherwise RubyGems
wouldn't be able to achieve real ri/rdoc integration. I hope this change
is general enough to allow other systems to leverage it (besides RPA,
other re-packagers like Debian/FreeBSD/etc could use it to provide
system-wide documentation for Ruby software).

If the RubyGems team doesn't do so, I could try to provide a patch to
allow ri integration, independently from the package/port manager.

IMHO it is important not to hinder the work of other re-packagers.

(*) Since RPA/rpa-base has not been declared the Standard, I hesitate to
ask 3rd parties to change their sw. to suit my needs. This is consistent
with repackaging stuff myself instead of asking the developers to do it
for me, which makes sense since RPA's goals are so much more ambitious
than RubyGems'.

 

[Dave Thomas]

The package is misnamed. I should have called it ri-rpa-support;
it is not a complete rdoc,

Thanks - it would be great if you could rename it: having two different
things both called RDoc is confusing.

Now, I hear the standard ri will be modified because otherwise RubyGems
wouldn't be able to achieve real ri/rdoc integration.

That's news to me AFAIK, the gems team is using the off-the-shelf
rdoc/ri.

However, if there are features I could add that would help all you
packaging folk, just let me know.

Cheers

Dave

 

[Mauricio Fernández]

That's news to me AFAIK, the gems team is using the off-the-shelf
rdoc/ri.

However, if there are features I could add that would help all you
packaging folk, just let me know.

I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

#SOME WORK DONE Figure out what to do about "ri" integration. Dave
is open to modifying ri itself if it doesn't have a negative impact
on the existing ri functionality. MUCH better than creating ri-gems or
some such crap

(I do share the implicit "ri-rpa == crap" assessment , but it exists
currently as a sub-optimal solution for the reasons stated in my
prev. msg)

 

[Dave Thomas]

I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

#SOME WORK DONE Figure out what to do about "ri" integration. Dave
is open to modifying ri itself

I don't think you need feel misled; Chad's statement is inconsistent
with what I said you you earlier: I _am_ open to suggestions from both
the gems folks and the rpa folks on things that would make integration
with their projects easier. Right now, the gems folks appear not to
need anything extra (I chatted with Chad about this for a while), but
if they change their minds, I'll listen. Similarly if the rpa folks
want new features, they just need to ask.

My only constraint is that any change we make shouldn't hurt rdoc/ri in
general. The major stumbling block to all of the packaging systems that
I see is handling installed packages that extend existing classes.
These work fine on installation, but I don't know how to handle the
uninstall, as stuff from the package may have been added to preexisting
descriptions.

Cheers

Dave

 

[Mauricio Fernández]

My only constraint is that any change we make shouldn't hurt rdoc/ri in
general. The major stumbling block to all of the packaging systems that
I see is handling installed packages that extend existing classes.
These work fine on installation, but I don't know how to handle the
uninstall, as stuff from the package may have been added to preexisting
descriptions.

Yes, that's the fundamental problem (and some associated usability issues)
I would like to solve in a general way. It might require some non-trivial
changes to ri/rdoc though... I'll try to explore some possibilities in
ri-rpa, prior to a possible merge.

 

[Richard Kilmer]

I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

You were misled? This is just some notes that I typed up relayed from Chad
on some final things we wanted to get done...not a general communications to
the broader community. No problem with reading it obviously but don't take
it as a message. The below mentioned item says Dave is open to changing
ri...in general...based on community feedback...he always has been. We can
obviously add our own version of ri, but we did not like the idea. Don't
take it personally

 

[Mauricio Fernández]

I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

[...]
Don't take it personally

I should have emphasized the smiley )

No offense taken

 

[Chad Fowler]

You were misled? This is just some notes that I typed up relayed from Chad
on some final things we wanted to get done...not a general communications to
the broader community. No problem with reading it obviously but don't take
it as a message. The below mentioned item says Dave is open to changing
ri...in general...based on community feedback...he always has been. We can
obviously add our own version of ri, but we did not like the idea. Don't
take it personally

Right. This wasn't meant to be a dig. ri-gems and ri-rpa are
obviously suboptimal solutions. Uninstall remains an issue, but we
may be willing to just make that compromise. After all, it's an
inherent (and IMO acceptable) limitation of the way ri works right
now. A major reason we don't think/hear about it much is that there
is no obvious, clean way to uninstall libraries when not using a
system like RubyGems or RPA-base.

As for ambition, don't be so quick to judge. Wait until this time
next year....

 

[Austin Ziegler]

Doesn't ri have a problem if two parts of the class are defined in
--ri-system and --ri-site, much less a "local" directory?

-austin

 

[Mauricio Fernández]

You were misled? This is just some notes that I typed up relayed from Chad
on some final things we wanted to get done...not a general communications to
the broader community. No problem with reading it obviously but don't take
it as a message. The below mentioned item says Dave is open to changing
ri...in general...based on community feedback...he always has been. We can
obviously add our own version of ri, but we did not like the idea. Don't
take it personally

mmmm I was wondering why both you & Dave were attaching such an
importance to the word 'misled'. It seems my condition of non-native
English speaker might well be the culprit

dictionary.com returns

mis·lead ( P ) Pronunciation Key (ms-ld)
tr.v. mis··led, (-ld) mis·lead·ing, mis·leads

1. To lead in the wrong direction.
2. To lead into error of thought or action, especially by intentionally
deceiving. See Synonyms at deceive.

For the record, I obviously meant a softer (1)... I didn't want to imply
that you deliberately deceived me on purpose; I was just confused. I
didn't mean to blame you for that

 

[Dave Thomas]

Doesn't ri have a problem if two parts of the class are defined in
--ri-system and --ri-site, much less a "local" directory?

Yup! Currently it assumes that any one class is defined in one place,
as I hadn't anticipated that
the packaging folks would install into many different documentation
directories. When I get this book project finished, I'll be trying to
work with anyone who's interested to change this behavior to better
suit their models.


Cheers

Dave

 

[Austin Ziegler]

Yup! Currently it assumes that any one class is defined in one place,
as I hadn't anticipated that
the packaging folks would install into many different documentation
directories. When I get this book project finished, I'll be trying to
work with anyone who's interested to change this behavior to better
suit their models.

Right. I think that this is something that can be dealt with
regardless of the model by the use of a (for lack of a better term)
RI_PATH similar to MAN_PATH. Then, RPA and RubyGems can add to or
remove from a standard RI_PATH location "at will" (or locations; I
would suggest that the RI_PATH could be stored in the site directory,
the system directory, and optionally the "local" directory).

Right now, without even using one of the main packaging systems, I can do:

% rdoc --ri-system diff/lcs

If I have previously run rdoc/ri generation for Ruby as a whole to
--ri-site, then when I do "ri Array", I will no longer be able to see
the general ri documentation for Array (because Diff::LCS includes an
extension to Array). (There also appears to be a problem with merging
last time I checked this; I think I sent a patch that should fix that,
though. Merging should be the default) I think that it will also cause
problems if I generate the ri documentation in the "local/home"
directory.

As long as ri knows where to find various YAML files (e.g., RI_PATH),
then whatever solution is used to fix the existing problem will fix
the problem for packagers.

-austin

 

[James Britt]

I just tried to install rpa-base-0.2.0b on a Win2K machine, with no luck.

First, it keeps asking me to modify the installation prefix, although on
each step the prefix is really just a variation on what has gone before;
you'd think it would keep track of what I just entered and use that to
derive the next path option. But no matter. Even after explicitly
entering the paths, the installation fails.

(Here I'm trying to install the packages into c:/ruby-rpa/ and related
subdirectories)

c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
c:/ruby-rpa/c: (Errno::EINVAL)

Has this been tested on Windows? Is it not meant for Windows users?

Thanks,

James

P.S.

A recent blog entry at
http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
says,

"I have invited the people from ruby-talk to request packages for the
Ruby Production Archive. So far the response has been a bit
disappointing; seemingly no Rubyist wants to use software packaged with
some care, or maybe it’s just that the 114 packages currently available
cover all needs?"

I'm sure Mauricio meant no disrespect, but this seems to imply that
packages currently available from RubyForge and elsewhere are *not*
packaged with some care. No doubt some of these *are* fairly
half-assed, but there may be many other reasons why people prefer not to
use rpa; poor Windows support being a real possibility.

 

[Aredridel]

A recent blog entry at

http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
says,

"I have invited the people from ruby-talk to request packages for the
Ruby Production Archive. So far the response has been a bit
disappointing; seemingly no Rubyist wants to use software packaged with
some care, or maybe it¢s just that the 114 packages currently available
cover all needs?"

It's damn good! A fair bit ahead of where I am. Everything I currently
use is in there, my own ruby-xattr aside.

I'm sure Mauricio meant no disrespect, but this seems to imply that
packages currently available from RubyForge and elsewhere are *not*
packaged with some care. No doubt some of these *are* fairly
half-assed, but there may be many other reasons why people prefer not to
use rpa; poor Windows support being a real possibility.

I can testify as to the varying quality of the author's packaging. I've
been working really hard on building RPM specs for Ruby packages for the
PLD distro, and it's tough, slow going. Some things (notably using a
modern setup.rb from Minero Aoki) are very easy. Others I've had to
fight with a lot, trying to get them to comply with the Linux Filesystem
Heirarchy Standard and other requirements. It's not easy.

I'm looking forward to trying rpa-base soon -- I haven't had the time (I
spent four hours trying to figure out why Ruby wouldn't compile on Sparc
or Alpha processors, only to find it was the Oniguruma preview failing
on some architectures)

For RPA, I can see windows support being important. I imagine that
limits its usage by about half.

Ari

 

[David Ross]

As mentioned in other emails. Windows is a target
platform for it to work on. RPA-base might be a
development release, but it works very well.

Batsman: Work work work

http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html

It's damn good! A fair bit ahead of where I am.
Everything I currently
use is in there, my own ruby-xattr aside.

possibility.

I can testify as to the varying quality of the
author's packaging. I've
been working really hard on building RPM specs for
Ruby packages for the
PLD distro, and it's tough, slow going. Some things
(notably using a
modern setup.rb from Minero Aoki) are very easy.
Others I've had to
fight with a lot, trying to get them to comply with
the Linux Filesystem
Heirarchy Standard and other requirements. It's not
easy.

I'm looking forward to trying rpa-base soon -- I
haven't had the time (I
spent four hours trying to figure out why Ruby
wouldn't compile on Sparc
or Alpha processors, only to find it was the
Oniguruma preview failing
on some architectures)

For RPA, I can see windows support being important.
I imagine that
limits its usage by about half.

Ari

----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------



_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

 

[Mauricio Fernández]

I just tried to install rpa-base-0.2.0b on a Win2K machine, with no luck.

First, it keeps asking me to modify the installation prefix, although on
each step the prefix is really just a variation on what has gone before;
you'd think it would keep track of what I just entered and use that to
derive the next path option. But no matter. Even after explicitly
entering the paths, the installation fails.

(Here I'm trying to install the packages into c:/ruby-rpa/ and related
subdirectories)

c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
c:/ruby-rpa/c: (Errno::EINVAL)

Has this been tested on Windows? Is it not meant for Windows users?

It has been tested on Win32. I myself have tried it on WinXP and it
worked fine there (I've often installed instiki in a couple minutes and
verified it ran fine for instance; I also installed Rails that way and
toyed with it, using the WEBrick dispatcher).

I believe you triggered a bug in the bootstrap phase related to the use
of a $prefix different from the one Ruby is installed under.

Could you try to install it under c:\ruby (you can later remove it with
rpa remove rpa-base and nothing will have been modified) to confirm
this? This should be safe since rpa-base will not overwrite anything
unless you tell it explicitly that it's ok (--force), and installations
are atomic.

I'll look into the possible bug and hopefully solve it soon.

 

[Mauricio Fernández]

(Here I'm trying to install the packages into c:/ruby-rpa/ and related
subdirectories)

c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
c:/ruby-rpa/c: (Errno::EINVAL)

Thank you for your report. It helped me find a stupid bug which was triggered
when one didn't use ruby's own $prefix.

Since the issue affects the bootstrapping phase (i.e. can't be fixed
with a normal self-upgrade), I have decided to release 0.2.1pre1, available
at http://rubyforge.org/frs/?group_id=265. Please tell me if it solves
your problems.

Please keep in mind the following:
* when answering to the questions in the bootstrap phase, only the first
path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
normally on win32). The others are relative to the former and the
default values should be perfectly fine.
* setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
but not 100% sure).
As of now, it is probably better to just install into the normal
$prefix, since rpa-base provides enough guarantees to make sure it
won't end up cluttered with half-installed RPA ports.
Support for per-user installations is planned and might be done in
time for 0.3.0.

For your reference, here's the patch that fixes the problem you
reported, I believe.

--- lib/rpa/helper.rb (revision 765)
+++ lib/rpa/helper.rb (revision 766)
@@ -471,7 +471,7 @@
def run(installer)
super
sitelibdir = ::Config::CONFIG["sitelibdir"]
- sitelibdir.gsub!(/^#{Regexp.escape @config["prefix"]}/, "")
+ sitelibdir.gsub!(/^#{Regexp.escape:Config::CONFIG["prefix"])}/, "")
do_copy(installer, sitelibdir)
end

there may be many other reasons why people prefer not to
use rpa; poor Windows support being a real possibility.

There are good reasons for using both RubyGems and rpa-base, and you
can indeed use them both at a time.

I am sure more bugs will be found in rpa-base's codebase, just as in
any other piece of sw.; I believe the bases are solid, though (I haven't
touched the transactional code lately, but last time I did the count was
at 500000 successful transactions since the last real bug in that area).
So far I've managed to fix all reported bugs in under 1-2 days (those
that were reported via IRC were typically fixed within a few hours).

Now, regarding my original question, is there anything you'd like to
see packaged? ;-)

 

[James Britt]

Thank you for your report. It helped me find a stupid bug which was triggered
when one didn't use ruby's own $prefix.

Sweet. Thanks.

Since the issue affects the bootstrapping phase (i.e. can't be fixed
with a normal self-upgrade), I have decided to release 0.2.1pre1, available
at http://rubyforge.org/frs/?group_id=265. Please tell me if it solves
your problems.

Please keep in mind the following:
* when answering to the questions in the bootstrap phase, only the first
path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
normally on win32). The others are relative to the former and the
default values should be perfectly fine.

Ah. I thought the default paths, as presented by the installer, were
complete paths. So I kept entering complete paths. The prompts gave no
indication that my earlier paths would be reused to build the other paths.

* setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
but not 100% sure).
As of now, it is probably better to just install into the normal
$prefix, since rpa-base provides enough guarantees to make sure it
won't end up cluttered with half-installed RPA ports.

Are you *sure*? I've had enough issues with
installing/uninstalling/reinstalling assorted versions of the 1-click
package. I don't want any overlap between this and my main ruby
installation.

Support for per-user installations is planned and might be done in
time for 0.3.0.
Nice.

...



There are good reasons for using both RubyGems and rpa-base, and you
can indeed use them both at a time.

I am sure more bugs will be found in rpa-base's codebase, just as in
any other piece of sw.; I believe the bases are solid, though (I haven't
touched the transactional code lately, but last time I did the count was
at 500000 successful transactions since the last real bug in that area).
So far I've managed to fix all reported bugs in under 1-2 days (those
that were reported via IRC were typically fixed within a few hours).

Now, regarding my original question, is there anything you'd like to
see packaged? ;-)

I don't know yet. I need to see how much disk space this takes up as
is, and see what's installed, and what I might use. You've probably
covered all the things I need. I have a few alpha/beta projects on
rubyforge. They tend have been created to scratch a personal itch, so
if they're not currently on your list then it's unlikely there is much
demand for them.

I'll go see if I can get this to play well on my laptop.

Thanks,

James