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

In short, what I suggest is the following: 1. modify PUI such that can install and most import **de-install** lisp programs which are in xemacs package (pkg) Format (3rd party packages) WHY??? A. installing of pkg, even a 3rd party one like vm or x-symbol, is a snap, no byte compiling, no path have to be set, however B. *de Installation* is a horror because of the package hierarchy. So one has to visit (inside the pkg directory) the /etc, /info /lisp /man /pkginfo directory in order to delete the relevant files. So we have the absurd situation that installing a non-pkg lisp package is more difficult than a pkg one, but *de Installation* is more complicated. C. People may want to install non official pkg, since some of the official ones are outdated. 2. Provide additionally information about the version number of the original (non-pkg) distribution, something like: Latest Installed Package name Vers. Vers. Description ============================================================== [snip] - auctex 1.32 ----- Basic TeX/LaTeX support (o-version 10g) ^^^^^^^^^^^^^^^^ - bbdb 1.21 ----- The Big Brother Data Base (o-version 2.34) ^^^^^^^^^^^^^^^^ 3. Explain under which conditions a 3rd party package enter the circle of official Xemacs packages. I can only think here of X-symbols which has been ignorated for years. 4. Provide a generic Makefile and Xemacs.rules for people interested to build 3rd party packages. At the weekend I tried to write a Makefile to generate a pkg, but it looks not this simple to me. I am not sure that I understand your comment: Stephen J. Turnbull writes: Let us take the following example, I untar x-symbol.src.tgz, which is not in pkg binball format, in /tmp. It's Makefile has the target binball to generate a pkg. Now if you compile this in /tmp, the resulting pkg is not _valid_? 5. Provide the Makefiles and Xemacs.rules of the official Xemacs packages for the authors of the original non (pkg)packages, say send such a Makefile for AUCTeX to David Karstrup, who now maintains AUCTeX; I picked up this example because the Xemacs released package is quite behind the official version. (I remember a flame going between Stephen and Eli about the xemacs package system, in which it is was pointed out that GNU emacs shipped a two years old gnus! However now the case for AUCTeX does not look much better!) Here is my understanding of a packing systems in general. A package system, such as RPM or deb (or Xemacs package) has the following purposes: i. It manages programs, installs, desinstalls and upgrades them, in a certain Format (.rpm, .deb), by protocolling these steps in a common system wide database. ii. It check the dependencies necessary for this process. iii. It allows to download and upgrade package provided by an official distribution. (RPM offers this relatively lately and has been widely critied for failure). iv. It offers tools for producing such package, ie specifiy .spec files for RPM v. There exists one or more (g)ui for simplifying the process in point 1, such as xrpm or yast for the RPM system. vi. There exist programs which simplify point 4, such as alien. Name | RPM | Deb | xemacs-package Packte Format | .rpm | .deb | .pgk check dep | yes | yes | ? Data base name | various in /var | ? | package-index.LATEST.pgp spec file | .spec | ? | Xemacs.rules (gui) | xrpm, yast | ? | pui Here some details on what PUI could do for 3rd party pkg. Like M-x pui-add-install-directory-for-3rdparty-pack RET ~/mystuff/ RET now pui reads a data base which is stored, say, at top of prefix/xemacs/site-packages named package-index.3party.pgp M-x pui-list-packages-3rdparty RET according to the content of this file, the packages located in /tmp/ are flagged as not installed or installed: Now the Installation process may start. *Advantage*: the destallation is now ruled by the information in database in prefix/xemacs/site-packages Having such a feature would may be encourage more people to offer their distribution as a Xemacs package. Not really true: Preview latex (like bbdb) offers the possibility to generate a a pseudo-package. That is during the make process, one can specify the package directory and then the relevant files are copied into it, however without makeing a pkg tar ball. Uwe Brauer