Re: To All Package Maintainers & Would-be Maintainers.

Simon> On 20 Feb 2001, Steve Youngs wrote: SJ> Silly Ideas Dept: use .rpm or .deb's? They have sufficiently SJ> complex dependency systems, and more importantly; OTHER people SJ> spend time improving the packaging system. It's possible to I think the problem will be that they will do hardly any work on the parts we need the most work done on; we'll have to do that all ourselves. See below. SJ> setup multiple rpm databases, and it works even as non-root SJ> users. Simon> RPM (and I think also DEB) run on more than linux. They Simon> aren't much different from a tar-ball with some versioning Simon> and installation instructions. The Debian stuff has historically been very hard to build on a non-Debian system. RPM has a better record in this respect. (At least in my experience.) RPM has the advantage that it is much more monolithic at this point (the Debian package system is now spread out across several .so libraries as well as Perl libraries, not to mention several alternative front ends and package-construction assistants). I'm a Debian user myself, but I don't trust their packaging system to be portable or robust anymore. (Admittedly, I'm using unstable.) Simon> The problem with sticking to tar.gz or coming up with our Simon> own system is that it will require quite some work to match Simon> the packaging functionality one expects in a package Simon> handling system. This is the real sticking point. The problem is that the dependency obeying part of the package system is (by comparison) trivial. The "functionality one expects" is dependency _generation_. We will get _zero_ help from the Deb and RH crews on this. We will have to write our own dependency generators and stuff like that. But in fact, we have most of what we need for that: the loader and/or the byte compiler does something quite similar. Also, it's not clear to me that the dependency "degrees" supported by dpkg and rpm are appropriate to Lisp libraries. Simon> Note that I'm not saying that switching to RPM won't mean Simon> work, but in the long run it might be nice to use some Simon> packaging system. We could also use a hybrid approach: prototype the dependency graph analysis stuff, and the dependency generators, in Elisp, and see if we can then get similar, robust, portable functionality from one of the externally maintained pms's. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."