From: ser@... (Sean Russell) Date: 2003-04-08T01:29:06+09:00 Subject: Re: Call for standardised package installation procedure "James Britt" wrote in message news:... > 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