ok Nope, I thought after all about autex: offical package is still 10.g (at least some weeks ago). Preview recommends 11.11 (well 10.g also worked, but I changed to 11.11 just in case)

Stephen J. Turnbull writes: ok > Uwe> 4. May be that has been asked already, but are there plans to > Uwe> write a tool, which allows to convert an already compiled > Uwe> package to to the xemacs package standard?. I am thinking of > Uwe> something equivalent to ALIEN for tgz2rpm. > No. It's a bad idea to simply install a precompiled package from > somewhere. That goes together with my question 1+2, that is the philosophy is that pui does not support 3rd party packages??. Please if you find the time tell me the answer to these questions or point me a url or something. Thanks > The process could be made a lot easier, but we plan to rearrange the > package hierarchy so that each package has its own subdirectory under > the package hierarchy root with lisp, etc, man, and so on > subsubdirectories, instead of the current layout with lisp and other > subdirectories under the package root, with package-specific > subsubdirectories. That would require rewriting any such tools > completely. So this will have to wait for a while. That looks for me the right thing to do. To have all in the same subdirectory looks somehow freighting to me.

On 20 May 2002, Stephen J. Turnbull mused: Look at emacs-w3m: it has a nice package installation system. (I copied much of preview-latex's xemacs package installer from it.) The w3m people don't create a _pkg.el file or pkginfo file, though: preview-latex does that as well. (The package version number used is the date of release, like `2002.0521' --- that should give ample flexibility for additional updates, unless we want to do more than one release a day!) (I don't know whether preview-latex gets that right. I shall check. I know `make install' puts the site-lisp in the right place, is all.) -- `There are not words enough to describe how fucked up imake is.' --- Peter da Silva

Now that there seems to be some discussion about the future of the package system, I'll throw in some ideas. This is not directly related to the thread [1], so I'm replying to the list only (as well as xemacs-design). Versioned requirements could be useful, especially for packages. We do know that package A needs version x.xx of package B to work properly, so PUI could handle these for the user, like "If you're installing this, you will also need to upgrade that." A simple "greater-than-or-equal-to" dependency would probably be enough, at least to begin with. This would be useful for core (XEmacs) versions too, so PUI could tell "You can install this only if you have XEmacs x.x.xx." or maybe would not show these packages to the user at all. But this could be difficult to implement due to different supported generations, eg. 21.1.xx, 21.4.xx and 21.5.xx... IMO, the package system version check would not be good enough. Also, the syntax should not break backwards compatibility. Something like RPM [2] does, like "REQUIRES = my-package >= 1.23, your-package > 2.02 ..." might be good, or whatever make will grok. But this must not break older XEmacsen, at least for the package installation part. Maybe it would be possible to sacrifice the ability to _build_ these packages with older versions? Another idea; when package A does not _require_ package B, but having B around would bring in some extra goodies to A's functionality; a RECOMMENDS feature could help. Again, maybe versioned as said above. There's already some discussion about this in [3]. Oh, and then a (versioned?) CONFLICTS relation between packages that don't coexist nicely... [1] <http://list-archive.xemacs.org/xemacs-beta/200205/msg00353.html> [2] <http://www.rpm.org/max-rpm/ch-rpm-depend.html> [3] <http://list-archive.xemacs.org/xemacs-design/200203/msg00001.html> Cheers, -- Ville Skyttä ville.skytta(a)xemacs.org

On Tue, 2002-05-21 at 23:55, A.J. Rossini wrote: Yes, at least CONFLICTS should be handled with care. An example case would be packages "skk" (the one we have) and "ddskk" [1]. I don't really know anything about these except that Red Hat is replacing the official XEmacs skk package with ddskk in their RPMs. Maybe these two would really conflict? [1] <http://openlab.ring.gr.jp/skk/> -- Ville Skyttä ville.skytta(a)xemacs.org

On Wed, 2002-05-22 at 00:04, Valdis.Kletnieks(a)vt.edu wrote: Hmm, something like these in Frobozz 1.13 Makefile: REQUIRES = Moby-Grape >= 1.3.4, Moby-Grape < 2.0 REQUIRES = 1.3.4 <= Moby-Grape < 2.0 REQUIRES = Moby-Grape >= 1.3.4 CONFLICTS = Moby-Grape >= 2.0 Been there too... Cheers, -- Ville Skyttä ville.skytta(a)xemacs.org

Alex> Maybe we should all move to apt-get... No Debian Perl please. Even Perl core developers admit that Debian makes all Perl look bad. :-P So here's the rub: who's going to create that database (and later keep it up-to-date)? I don't want that job, thank you. Steve Youngs is already working flat-out. Remember, a substantial minority, perhaps a majority, of our packages are orphans without an external maintainer. How are we going to make sure that packages with version dependencies can actually fulfill them? (I wanted to try some Debian package the other day, but it wouldn't install because the dependency was == and the installed dependency library was too recent. This happens a _lot_ with GTK libraries.) What do we do about packages like JDE that not only depend on pre-release versions of other packages, but install them? Wouldn't this effort be better directed at the 800-pound gorilla of dependencies, GNU vs XEmacs? And maybe on disciplining Ben Wing and other people who are creating APIs willy-nilly. And doing APEL right? Is this really that big a deal? I don't see lots of problems in user land (c.e.x and xemacs-beta) that really look like dependency issues. Instead, most of the time people need to upgrade for out-and-out bug fixes. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai writes: As Stephen has written in another post, most of the packages don't have maintainers. norbert.

Valdis.Kletnieks(a)vt.edu writes: Well, and then somebody (Alice) sends a bug report. And somebody else (Bob) finds out about this conflict. Bob tells Alice about it. In the future, Bob just needs to frob foo's Makefile, too. Of course, this might not be practical. Instead, some other maintainer will read the whole exchange and then frob foo's Makefile. (In the end, foo should be fixed to cope with bar-1.7, anyway.) kai -- Silence is foo!

On Wed, 22 May 2002, Alex Schroeder uttered the following: If GNU Emacs had as many packages as XEmacs, that might change. (How many people download the sumos rather than the individual packages? Anyone know?) -- `There are not words enough to describe how fucked up imake is.' --- Peter da Silva

Ville> On Thu, 2002-05-23 at 00:24, Nix wrote: [Alec Schroeder, I think] Emacs is sufficiently full-featured that they probably don't know what they're missing. XEmacs users, on the other hand, regularly post "the package system is really helpful! if only it would ...". I think most Unix people download the sumos for initial install; use pui for upgrades later. This probably is not true for netinstaller customers, since they can select packages from the same UI as they select XEmacs binaries. But I think most of them use PUI not netinstaller for upgrades. Ville> ...and if I've understood correctly, the Sumos shouldn't Ville> really exist (no references available as of now, but I know Ville> I've seen some comments against them somewhere). True, but possibly not in the sense you mean. The main complaint against the SUMO is that we don't distribute new releases of XEmacs as xemacs-21.4.8+sumo-20011219+mule-sumo-20011219.tar.gz. Ville> I think that a big Sumo tarball gives Ville> users/admins/distro-makers/those-who-don't-use-pui a strong Ville> hint like "These packages have been tested to interoperate Ville> well, install this and don't worry about the dependencies." Ville> Well, at least stronger than N different packages in the Ville> same dir, even though the dir is for stable packages. Ville> IMHO, this kind of limits the power of the package system. This is possible, but I've seen no evidence (in the form of questions on xemacs-beta or c.e.x) to indicate that it is true. On the contrary, Adrian posts (often 3 or 4 times a day) "Update to net-utils 1.43" and people Just Do It, nobody ever asks how. The basic use is _there_, it does what typical users want it to do: give them Emacs capabilities they need (or we ask them to install!) without muss or fuss. The limits to the power of the package system from my point of view are: o no help for build from source people -- we should support them better o the pui internals were architected by Motie watchmakers, no rhyme or reason but some how they work o Red Hat (SuSE, et al) hoses us every so often with gratuitous changes to their FTP clients, and we're stuck with an annoying EFS bootstrap problem; Mike Sperber's conservatism about updating EFS doesn't help with this Ville> I also think that a more comprehensive and more enforced Ville> dependency system could have a positive effect on this; Ville> still assuming that Sumos are not considered a good thing. Ville> Versioned dependencies wouldn't hurt here, I guess... Actually, I think the only noticable effects of versioned dependencies would be slightly fewer bug reports to package maintainers, and massively increased complaints about the package system not doing its job correctly. I think it's worth worrying about dependency issues for the future, we may get to the point where dependencies recurse as much as ten layers deep as in Debian. But right now we rarely see recursion deeper than 2, and most packages are chock-full of compatibility cruft---it will take massive effort to increase that depth by moving compatibility and sub-package functionality to separate packages. Eg consider Gnus, which has mml, message, the various backends, etc all split out into nominal subpackages. Does anybody use them? No. Could we really split them into separate packages? I doubt it. On the other hand, consider JDE, which is the only substantial user of eieio and semantic, and thus we distribute whatever version JDE requires. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

david> I've always used netinstaller -- it's really simple (thanks Andy). If david> only the netinstaller downloaded the new versions of itself when they david> came out. Perhaps it too should be treated as a package like the david> XEmacs binaries. :-) The Cygwin installer does this now (updated a system last night), so... best, -tony -- A.J. Rossini Rsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics rossini(a)u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org -------------- http://software.biostat.washington.edu/ ---------------- FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX (my friday location is usually completely unpredictable.)

SY> But they (Sumos) are a good thing. And besides, dependency SY> related problems reported to xemacs-beta or c.e.x are *VERY* SY> rare [2]. Typically they're not recognized as such until they're in the upstream maintainer's hands. Guess who all the people who are pushing for better dependencies are. ;-) SY> [2] I don't think I have *ever* seen one. Search on JDE+semantic+eieio. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

On Sun, 2002-05-26 at 02:15, Steve Youngs wrote: The "power" was a bad word choice, maybe "usefulness" would have been better. Anyway, what I am looking after is that XEmacs has a nice package system, why don't the majority of users (just a guess...) use it but download sumos instead? It would probably be less work and easier for everyone if we had (only) One Easy and Working Way to handle packages. Ah, I wasn't even aware of that (hmm, efs?). Agreed, this should be fixed somehow. Cheers, -- Ville Skyttä ville.skytta(a)xemacs.org

On Sun, 26 May 2002, youngs(a)xemacs.org wrote: The problem as I see it is that you are taking the developers' distinction of CORE vs PACKAGE and moving that into the users' space. Create a new idea called a DISTRIBUTION, where it is the CORE plus the bootstrapping packages. -Mark

MT> Create a new idea called a DISTRIBUTION, where it is the CORE MT> plus the bootstrapping packages. SY> This is something that we are considering. I'm not sure how SY> far along things are though. SY> Steve T: What's the status on this? If you like I can channel SY> some of my time towards getting something working. I probably would not work on it for a couple months, I guess, but I would certainly help if somebody else takes the lead. The basic idea is simple: put a tarball of xemacs-base+EFS, alternatively the current SUMOs, in $srcdir/etc. Write a Lisp program to put the contents in "the expected place" using the path-finding routines Michael has designed. Add makefile targets for invoking the Lisp program to unpack the bootstrap package or the SUMO(s), and probably some routines to drop the admin directly into PUI (this makes sense even if you install the SUMO(s)). Some of the stuff you would have to vet anyway: the bootstrap package should be automatically generated, I think, and maybe kept as a separate module in CVS. Building it probably would require something in your build scripts similar to the SUMO but only for the minimal set. Possibly there need to be changes to PUI (mostly sanity-checking where the package-base file goes and stuff). I think it would be trivial to add the code to my script to roll these into the xemacs tarballs. The bootstrap package would become part of the standard xemacs-$version.tar.gz and xemacs-$version-src.tar.gz, both the regular and Mule SUMOs would be in a new tarball xemacs-$version-sumo.tar.gz. (Or maybe I should do as Martin always advocated and the +SUMO tarball would be xemacs-$version.tar.gz, the bootstrap tarball would be xemacs-$version-bootstrap.tar.gz.) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

giacomo> what i'd _really_ like would be the option of giacomo> accessing an _installed_ tree of packages transparently giacomo> using cvs+emacs Would rsync do? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

giacomo> Stephen J. Turnbull writes: >> >> giacomo> what i'd _really_ like would be the option of giacomo> accessing an _installed_ tree of packages transparently giacomo> using cvs+emacs giacomo> as i'm a naive user of cvs, i'd happily be a naive user of rsync... giacomo> rsync/cvs difference it's about downloading whole changed files giacomo> instead of diffs, isn't it? giacomo> and would you (xemacs.org, i mean) set up a rsync server? i hope giacomo> so, as it will be a BIG gain for 56k downloaders,,, Hi Giacomo, you'll be glad to hear that the XEmacs CVS repository is already available via rsync, even though we have not documented the fact yet. Try rsync -auvz --delete sunsite.dk::xemacscvs DESTDIR I even maintain a mirror on my Windows laptop, which I update every evening from home, where I have a fast network connection :-) Caio, Adrian giacomo> ciao -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

giacomo> Stephen J. Turnbull writes: giacomo> what i'd _really_ like would be the option of giacomo> accessing an _installed_ tree of packages transparently giacomo> using cvs+emacs giacomo> as i'm a naive user of cvs, i'd happily be a naive user of rsync... giacomo> rsync/cvs difference it's about downloading whole changed files giacomo> instead of diffs, isn't it? giacomo> and would you (xemacs.org, i mean) set up a rsync server? i hope giacomo> so, as it will be a BIG gain for 56k downloaders,,, apa> Hi Giacomo, apa> you'll be glad to hear that the XEmacs CVS repository is already apa> available via rsync, even though we have not documented the fact yet. apa> Try apa> rsync -auvz --delete sunsite.dk::xemacscvs DESTDIR apa> I even maintain a mirror on my Windows laptop, which I update every apa> evening from home, where I have a fast network connection :-) A> But this won't help with having packages INSTALLED IN PLACE, A> will it? (i.e. I thought you couldn't work right out of a copy No. We don't have a installed package hierarchy available by rsync or other means. A> of a checkout of the packages CVS repository, though I'd be A> really happy to be wrong :-). Sorry to disappoint you, but you're right :-) A> best, A> -tony A> -- A> A.J. Rossini Rsrch. Asst. Prof. of Biostatistics A> U. of Washington Biostatistics rossini(a)u.washington.edu A> FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org A> -------------- http://software.biostat.washington.edu/ ---------------- A> FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email A> UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX A> (my friday location is usually completely unpredictable.) -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

|--==> "gb" == giacomo boffi <giacomo.boffi(a)polimi.it&gt; writes: gb> but what do you think about the option of keeping an installed gb> package hierarchy on sunsite.dk? And available via rsync... I really like the sound of that. I wonder how workable it would be, and how hard would it be to set up and maintain? Definitely food for thought. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "gb" == giacomo boffi <giacomo.boffi(a)polimi.it&gt; writes: gb> Steve Youngs writes: gb> but what do you think about the option of keeping an gb> installed package hierarchy on sunsite.dk? gb> probably it's not harder than typing gb> "rsync installedtree sunsite.dk:installedtree" gb> when you have a) rsynch access to sunsite.dk and b) an installed gb> package tree on your local machine... I meant from my point of view (the server side). -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

AJR> But this won't help with having packages INSTALLED IN PLACE, AJR> will it? (i.e. I thought you couldn't work right out of a AJR> copy of a checkout of the packages CVS repository, though I'd AJR> be really happy to be wrong :-). SY> No, you are correct, you can't run packages "in place". However, this may change; Michael has mentioned moving to a $package/{etc,lib-src,lisp,info,man,...} organization from the current {etc,lib-src,lisp,info,man,...}/$package setup. Further changes might be required to make run-in-place work, but that is the main barrier at the moment AFAIK. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

David Masterson writes: no, every pakage has already an entry in load-path... (insert (pp load-path)) ("/home/gb/lib/emacs/test" "/home/gb/lib/emacs" "/usr/local/lib/xemacs/site-lisp/" "/usr/local/lib/xemacs/site-lisp/edb/" "/usr/local/lib/xemacs/xemacs-packages/lisp/" "/usr/local/lib/xemacs/xemacs-packages/lisp/apel/" "/usr/local/lib/xemacs/xemacs-packages/lisp/auctex/" "/usr/local/lib/xemacs/xemacs-packages/lisp/bbdb/" "/usr/local/lib/xemacs/xemacs-packages/lisp/build/" ... "/usr/local/lib/xemacs/xemacs-packages/lisp/xemacs-base/" "/usr/local/lib/xemacs/xemacs-packages/lisp/xemacs-devel/" "/usr/local/lib/xemacs-21.5-b6/lisp/")

|--==> "DM" == David Masterson <dmaster(a)synopsys.com&gt; writes: SY> No, you are correct, you can't run packages "in place". DM> Won't that tend to vastly increase the size of load-path (etc.) and, DM> thus, slow down finding things? No, the load-path will still be the same size because nothing is getting added (or removed), just moved. However, the exec-path will grow a bit, and the search path for info docs will get astronomical. This is because in the current setup we only have a single 'lib-src' and 'info' directory for all the packages. [1] Changing to the suggested structure will mean that there will be a 'lib-src' and 'info' directory for each package that needs them. Footnotes: [1] mule-packages have their own lib-src and info as well. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

Adrian Aichner writes: thank you, it's good news indeed! (well, not a complete surprise, as stephen's reply to my 1st post seemed to hint such an occurrence...) won't that copy the whole cvs repository? isn't it a bit too much for a test or am i wrong? while we're at it, what i'd like to do is keep in sync only [a part of] the installed packages: do you think it's currently possible or i have to keep the whole source tree on my disk and to do the package builds by myself? well, it's time to go reading rsync(1) ciao

Kai.Grossjohann(a)cs.uni-dortmund.de (Kai writes: What I meant is that it happened from time to time that people were complaining that package X didn't work. It was clear from the error message that some package was missing. I then mentioned about the Sumo tarball (which seemed to me an easy way to install the missing packages without having to do trial and error). It took a while to explain what Sumo is, but after that I think they were happy. The implication is that the Sumo tarball isn't advertised enough, I think. kai -- Silence is foo!

SY> |--==> "n" == nix <nix(a)esperi.demon.co.uk&gt; writes: n> (How many people download the sumos rather than the individual n> packages? Anyone know?) SY> I don't know for sure, but I'd guess that the number is pretty high. Here is actual data suggesting that individual package downloads (via ftp at least) are more common than sumo downloads via ftp: http://www.tux.org/wusage/usage_200205.html#TOPURLS SY> -- SY> |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |------------------------------------&lt;youngs(a)xemacs.org&gt;---| -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

I'm almost certain these stats are skewed by the netinstaller which does individual package downloads. I'm intrigued that setup.ini is top. I guess this is because it does not change name whereas the tarballs do. Someone needs to update the installshield dist - it obviously is quite popular. andy

You should look at the design draft I did back in 1999. It handles (would handle :-( ) most of what you suggest. http://list-archive.xemacs.org/xemacs-beta/199907/msg00143.html One of these days, I'll get with it, really ... -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

nix> On 21 May 2002, Adrian Aichner stated: nix> Fixable by a sub-day number, viz nix> 2002.040500 (01, 02, 03...) Looks like a date to me, why not make it one? How about ISO8601 compliant 20020405Z1432 (released at 1432 UTC). nix> I'll make that change to preview-latex now. ;) nix> Of course. (I tend to mean `UTC' when I say `time' or `date' anyway; nix> count it up to .uk provincialism... ;) ) Make sure not to switch to summertime, then! :-) nix> -- nix> `There are not words enough to describe how fucked up imake is.' nix> --- Peter da Silva -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

(I did not sent this to the list but only to Stephen, sorry) Stephen J. Turnbull writes: So did I, but now since I know what the pui is or should be capable off I am curious. As is x-symbol for example Now to another point: I am using xemacs-21.1.14 (I know I should upgrade) but the Sumo package from late march: now when calling (pui-list-packages) I see: Latest Installed Package name Vers. Vers. Description =============================================================================== - Sun 1.12 ----- Support for Sparcworks. ada 1.09 1.10 Ada language support. apel 1.19 1.21 A Portable Emacs Library. auctex 1.22 1.30 Basic TeX/LaTeX support. That looks a little odd, but ok I have to downloaded via xemacs the upgrade of the packages. What is strange that pui-display-info display the info of the latest but not of the installed package! So in this case it tells me auctex version: 9.9p etc (1.22) but I have 10.g installed (1.30) if this is not a bug but intended I consider it as a misbehavior. Uwe Brauer

|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es&gt; writes: UB> 1. I want to download a new (let's say even a official) package to a UB> temporary directory and install/update it from there. So I thought UB> (pui-add-install-directory "~/tmp") would do the job, in the sense UB> that pui-list-package would list my all the package contained in UB> this directory and flag them as uninstall. This was not the case. For that to work you also needed to download the 'package-index.LATEST.pgp' (.gpg if using XEmacs 21.5) as well. And then you could: M-x pui-add-install-directory RET ~/tmp/ RET M-x package-get-update-base RET /path/to/package-index.LATEST.pgp RET M-x pui-list-packages RET Iff the packages in ~/tmp/ are listed in 'package-index.LATEST.pgp' they will show up in 'pui-list-packages'. The central part of the whole package system is the package-index file. Without that, you've got nothing. UB> 2. I want to list 3 party packages via pui-list-packages [...] UB> Maybe 3d party package are not meant to be controlled by pui? If UB> so I consider this as a severe disadvantage! At present, the XEmacs package system doesn't support 3rd party packages (those not distributed by us). And I agree with you, it is a huge disadvantage. If it's any consolation, implementing support for 3rd party packages is on my todo list. I'm not sure when I'll get it done, at this point it is just a few random thoughts floating around the dark recesses of my mind. :-) UB> 3. Version numbers: couldn't the package numbers coincide with the UB> version numbers of the maintainer? vm now does :), but auctex and UB> others do not. Yes pressing I will give this information, but UB> anyhow the convenience would be greater if the numbers coincided. There are two problems with trying to keep the version numbers in sync... 1) Sometimes we'll make a change to a package that'll force our version number up before the upstream maintainer releases a new version. 2) Quite often the upstream version number is incompatible with our version numbers. Ours are "x.xx" of type float, and as you could imagine, there are almost as many variations of a version number/string as there are packages. Besides, version numbers are such an arbitrary thing anyway. UB> 4. May be that has been asked already, but are there plans to write a UB> tool, which allows to convert an already compiled package to to the UB> xemacs package standard?. I am thinking of something equivalent to UB> ALIEN for tgz2rpm. Not that I'm aware of. I have talked about just such a tool with someone, but I don't think it ever got past the "wouldn't it be neat if..." stage. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es&gt; writes: UB> Steve Youngs writes: UB> Ah this was it. I think this information about downloading the UB> package-index.LATEST.pgp file in order to make an Installation from a UB> local directory, should be included in the manual and in the FAQ where UB> I cannot find it. Patches to the docs would be greatly appreciated. :-) UB> Maybe 3d party package are not meant to be controlled by pui? If UB> so I consider this as a severe disadvantage! UB> Would it be helpful to have a hack which just would manage 3rd party UB> packages in .xemacs or .xemacs/xemacs-packages and then later try to UB> merge it into the 'main' package tool? It could be. But 3rd party packages should go into: $prefix/lib/xemacs/site-packages/ -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

Uwe> OK, but this leads me to a general question: shouldn't docs Uwe> written by native English speakers? I see no need for that. Basically, if you're willing to write docs for code you didn't write, then your English is almost surely good enough. Otherwise it would be too painful for you. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py