“James Britt” james@jamesbritt.com wrote in message news:NGEDJNFKAGDNDOIPFPBDGECLDNAA.james@jamesbritt.com…
Is it that all packages need to use the same installation code, or that they
all implement an installer that follows a known interface? I would be
happy if every package had a script named install.rb that had a known
and consistent behavior. Many apps already have such a script, but they don’t all
do the same thing. For some, running it without args will install the code.
In other cases, it spits back a terse message that that you call it with some
cryptic args.
This is all very Ruby-oriented. The best thing, for users, is that
they install Ruby modules the same way they install any other
software. apt-get, emerge, rpm -Uvh, whatever. That said, we don’t
have much control over that, per se. The set of available Ruby
packages will always be larger than the set of available Ruby packages
for a distribution.
I agree that it is therefore nice to have a single, common interface
to installing (and uninstalling) Ruby packages outside of any
platforms package maintenance software. This really helps people not
using OS package management systems. When I unpack C-based software
on Linux and see “configure”, I get decidedly happier.
I don’t know much about other package management systems; I remember
hating RPM, but beyond that, my experience has been limited. I
certainly don’t think that having a uniform installer for Ruby is as
important for ebuilders; Portage is does a superlative job of making
ebuild generation and maintenance as easy as possible. In fact, for
projects with a low delta in their build/install mechanism, the amount
of work required to create a new ebuild for a new version of the
package is the cost of renaming a single file. It helps the original
ebuilder if the install mechanism supports the equivalent of “make
DESTDIR=”, but it isn’t absolutely necessary. I don’t believe that
Portage even takes advantage of any software’s “uninstall” mode – it
merely remembers what files it installed, and deletes them (if they
haven’t changed in the meantime).
It would be nice if even basic scripts included a scripted way to do installation,
but I’m leery of requirements for inclusion. Still, as others have mentioned, some
machine-readable bit that indicates the presence of a standard install method
would be a nice feature in the RAA.
Hm. Or, maybe an “Install” metadata, with possible values such as
“make”, “ant”, “setup.rb”, “bashing-your-head-between-two-bricks”, or
whatnot.
I’d be interested to hear from folks as to:
a) Why they do not include an installation script
For most people, probably overhead, or lack of need.
b) Why they do not list their code in the RAA at all (but do make it available
from, say, SourceForge or a personal home page)
This issue gets on my nerves, one way or another. I list REXML in RAA
and Freshmeat, and there are a couple of other popular places I could
probably usefully list it. Maintaining an entry in one list is fine.
Maintaining it in two is a pain in the ass, and maintaining it in
three… well, I won’t do it. It already takes me a few hours to
write a release notice, post it to RAA and Freshmeat, make an
announcement in C.L.R. and the REXML mailing list, submit an ebuild to
Gentoo, and test links in the various places to make sure they’re OK
– and that’s with a mostly automated distribution mechanism for
building the main REXML web page.
Now, if a software catalog supported some sort of XML-RPC mechanism
for posting updates, I’d be happy to add them to the list of places I
maintain entries. To my knowledge, neither RAA nor Freshmeat does
this; it is a fully interactive process to post updates, and, to be
honest, I’d rather be writing software.
This is where somebody embarasses me by pointing out that RAA or
Freshmeat does provide a web service interface to updating entries
– please … go ahead. I’d gladly eat that particular crow.
— SER
