From: Gregory Seidman Date: 2007-01-15T02:01:45+09:00 Subject: Re: A Heartfelt Plea for a Universal Open Source Package Management System [was Re: Tattle - The Ruby Census] On Sun, Jan 14, 2007 at 05:52:19AM +0900, M. Edward (Ed) Borasky wrote: > Chris Carter wrote: > >Under the same question, why can't a gem be a DEB, or why can't a perl > >package be a GEM, or a gem a perl package, or an R package, or a port? > > There's no reason it *can't* ... all I am saying is that there are some > very brilliant people spending significant amounts of time packaging > valuable open source software in multiple formats, and I think that's > wrong. When we speak of packaging systems we expect several features, among them: 1) anything that's installable comes in a single, downloadable file (e.g. .gem, .deb, .rpm) 2) there is a way of discovering which package(s) are needed for specific functionality 3) the package installation process, once initiated, results in fully installed and ready to use functionality 4) package files identify other packages on which their functionality depends 5) the installation process therefore retrieves the package we request and automatically retrieves all packages on which it depends, and installs them all It's really easy to get #1 working, and to keep #1 working when converting between packaging systems. There is the aforementioned gem2spec, which will turn a RubyGem into an RPM. There is alien, which will convert between RPM, .deb, Stampede (no idea), and tarball (Slackware). The resulting package will be installable on whatever target system, but that doesn't mean it will fulfill any of the other features mentioned above. Those of us who have been using Linux for enough years remember RPM Hell, which has been largely (though not completely) solved with the advent of apt-rpm, yum, YaST, and similar. The problem wasn't that the RPM format was inherently bad as a package format, the problem was that there was no clearly defined and rigorously adhered to naming convention for dependencies, nor significant quality control around third-party RPMs. Debian solved this problem by laying out strict naming guidelines, by making it much easier for packages that would otherwise be third-party to be included in the Debian repository, and by running automated tests on the packages in the repository to enforce quality control. (I'm not claiming it's perfect, but I don't believe any other packaging system/distribution has anywhere near as many packages or developers working together such that, in the stable distribution at least, installing a package will never step on the toes of another package and will always be installed with all of its dependencies.) There's a lot of overhead in all that, and generally special-purpose tools (or dedicated packagers) are involved in repackaging foreign packages for use on a Debian system. One example of this is java-pakcage, which provides the make-jpkg tool that will convert a binary installer downloaded from Sun (or, on PPC, IBM) into an installable .deb with an appropriate name, appropriate dependencies, and appropriate "provides" (as in, the package is named jdk-XXX-whatever but it provides java-compiler and java-runtime, on which other packages depend). I believe there is ongoing work to do the same for gems. The escape hatch, of course, is to install it in /usr/local and manage it separately, which is what I do and will continue to do until a gem-package is created to make them play nice with the rest of Debian. > Most of the common gems, for example, are wrapped in Gentoo > ebuilds. A Gentoo developer, most likely a volunteer, does that, so on > my system, I can either type "gem install --remote rails" and add a line > for rails to "/etc/portage/package.provided", or "emerge -v rails". > There's probably someone else that has to do this for Debian, and for > Red Hat/Fedora/CentOS, etc. And when a new Ruby package comes out, > there's a lag as it makes its way through the gem system to a .deb, a > .rpm, a .ebuild, etc. In addition, because of the labors of one > individual, a large number of R packages are packaged for Debian but > nobody has volunteered to do the same for Red Hat or Gentoo formats. [...] The point I'm making above is twofold: first, a universal packaging system requires a whole lot more than just a file format, it requires buy-in from everyone involved on naming conventions and file placement and a variety of other things; second, the best solution is not to have packagers doing the repackaging, but to have someone create a tool for the target package management system to convert packages from the foreign package management system. > M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P) --Greg