Neal> But if you update the packages via Tools/Packages, it will Neal> not notice the info.gz files and you will wind up with 2 Neal> sets of files. That should be easy enough to fix. Neal> Which brings us to another question. Is there an RPM spec Neal> included in the standard xemacs tarball? I think there Neal> should be. How do you propose to do that? Last I heard RH, Turbolinux, Mandrake, and SuSE at least all had slightly different sets of libs etc. And a couple of people are using RPM on Solaris. Can this be portable? If not, I don't really see the point. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

NDB> Which brings us to another question. Is there an RPM spec NDB> included in the standard xemacs tarball? I think there NDB> should be. SY> No. And there's not likely to ever be either. Could you expand on this? I see no reason why we shouldn't incorporate pms specs subject to the caveat that they can be written in such a way as to work on the user's system. Eg, I don't know about the Debian-distributed .debs (I believe they currently depend unacceptably on stuff like Xaw3d), but in general it's not hard to make a "generic" debian/rules. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

SY> We have our own PMS. It may not be perfect, but it's the only SY> one that we need to support. Funny. I don't see an "xemacs-binary" package in PUI. I admit I have a personal interest: I'm getting sick of having aptitude (one of the Debian front-ends) download and install GNU Emacs every so often simply because I don't have a Debian package that provides "emacsen" installed (although I have 3 or more versions of XEmacs and one GNU Emacs available...). I'd also like to get rid of the Debian 3rd party elisp bullshit. I can't use Debian 3rd party packages when we don't provide them yet, because they often auto-infect the system or don't use standard interfaces. I imagine RPMs are just as bad. If we could create a single Debian generic-package which would download and install an XEmacs package, that would be too cool for words. As for "support", yes, I'd be willing to support the generic .deb. But there's plenty of stuff that we distribute as "contrib". If somebody wants to supply a skeleton RPM spec that works x-rpm-platform, I see no reason not to include it. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

SY> Funny, I thought we were talking about the stuff in SY> /pub/xemacs/packages/. Only by accident. The OP's problem would occur for core Info files as well if he installed the XEmacs core over the distro's version. That operation is just a lot less common (primarily because of how confused RPM and dpkg get when you do that) than installing packages. SY> Providing I don't have to do anything to implement or support SY> this craziness in our packaging system, go for it, knock SY> yerself out. No, you wouldn't. The whole point (as far as packages go) would be to break RPM's kneecaps so it would grovel and say "I fell down and can't get up ... would you mind installing your own packages?" Then we'd kick it again to remind it to update its databases. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.