Re: PUI manages 3rd party packages: more RPM or DEB like

Ville> Doesn't PUI or package-admin-delete-binary-package do this Ville> for you (I'don't know, I don't remember using non-XEmacs Ville> packages)? See also Ville> <http://www.xemacs.org/Documentation/packageGuide.html#Upgrading:Removing_... package-admin-delete-binary-package is non-interactive, thus doesn't count as part of PUI. That is probably easily fixed, not by changing that function but by wrapping it in something to give it sane arguments and get confirmation, etc, in package-ui.el. If you look at package-ui.el, you'll see that list-packages unfortunately uses package-get-base for the package list itself, and does not consult packages-package-list to find out about local packages. This is probably also easily fixed. I think that for installation of 3rd party packages, we just set them up the way Pre-Releases is set up. The packager provides a local package-get-base list, and Tools | Packages | Sites needs a way to set up 3rd party sites. I think these are both worthwhile projects. They're several months away (maybe 3rd quarter?) on my personal list, though. Before that I would work on alternative transports (http and TRAMP, at least) for downloads. Ville> Stephen, could you fill in the blanks here, as well as on Ville> the "generic Makefile and XEmacs.rules" question? Sure. 1. "Broken packages" means "we cannot guarantee there will be no bugs if you do this", in fact, you can be pretty sure that you will run into bugs (the always inscrutable "can't call macros from compiled Lisp" variety). 2. The resulting package is probably not "valid." The package tools may not install it correctly, they need a MANIFEST.$package in the pkginfo directory to uninstall it, and the odds are pretty high that it will not provide a conformant auto-autoloads library and other meta information. The easiest way to get that stuff is cvs checkout package-control create packages/site-packages, drop the package files in a subdirectory of packages/site-packages, and create appropriate package-info.in and Makefile. In site-packages/Makefile you need exactly two lines: PACKAGES = <subdirectories containing packages here> include ../iterate.rules None of this is well-tested; it did work for me many moons ago, but there has been a lot of hacking on *.rules since then. 3. There are generic control files as well as documentation of their various options in C-h i g (lispref) Creating Packages RET. packages/XEmacs.rules has no user-servicable parts; look in packages/Local.rules for site configuration. This is documented in a sibling node, as well as copious comments in Local.rules.template. Ville> There is limited support for dependencies (they're build Ville> time ones only, but better than nothing at runtime as Ville> well). The issue of dependencies is extremely difficult. I am not at all a fan of the dependency systems implemented by dpkg or RPM. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.