Re: Call for standardised package installation procedure

"James Britt" <[e-mail]> wrote in message news:<[e-mail]>...
> 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