I agree. Since we have a package systemet it is a shame if it can't be used. The use case I feel as most important is when a user has downloaded the XEmacs binary using the packaging system of his OS distribution or installed the binary using an installer. That installation should then leave the system in a state where the internal package system can be used. (I build everything from source so I haven't tested this use case for years. Is this not working?) Having said that I also feel that a first time user might be better of using the package system of his OS distribution all together. Installing both the XEmacs binary and the packages using the OS-distribution. Can the info on xemacs.org be improved here? Finally for a user who installs the binary from source using configure. make etc is that a first time user? But if that procedure can be made easier, well why not. Steven has suggested using autogen.sh. The documentation on the web page should be made accurate if it is not. What else can be done? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Something like that, if the current text isn't good enough. All linux distros I have tested, a handfull, and cygwin contains install packages for the binaries and the packages. [...] That is a point in my reasoning. They, the distros, have on their own designed a way to install XEmacs and hopefully tested that it works on their platform. I think it is a good idea for a first time user to use that install method when trying out XEmacs. It is first when you don't like the way your distro has chosen to configure XEmacs or it is missing you should need to install it yourself. We can't see to that distributions do include XEmacs. A good goal for us could be to make it as simple as possible for the people maintaining the distributions to prepare XEmacs for their distro. How far we should go there is another questions. Apparently many distributions manage to wrap up XEmacs binaries and packages so it we might already be there. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On Tue, Aug 2, 2011 at 6:07 PM, Mats Lidell <matsl(a)xemacs.org&gt; wrote: it prompts you for what packages you want installed, with a few preset lists you can start from (Complete, minimalist, and recommended). However, it is impossible to deselect xemacs-base and efs. In fact, "minimalist" also includes texinfo, and edit-utils. Many OSes don't have xemacs in their package manager, and even if they do, its not necessarily the version I would want, or what would be best for a new user of xemacs. For instance, Slackware completely lacks an xemacs package in their repo. Arch has one, but only a patched version of the latest beta. Fedora has only beta versions. Suse has 21.5.29. Free Mandriva lacks xemacs altogether. In short, I wouldn't necessarily be able to use a binary version from my distro, and even if I could, I might not want to. But overlooking whether it is possible to get xemacs from my distro's repo, I wouldn't be very likely to try. The first time I installed xemacs, it was because I had heard of an alternative to emacs, and wanted to give it a shot. I went to xemacs.org, found the source, and installed using configure, make, etc. I never bothered looking in a package repo, as I didn't figure it was worth the time, unless it was a difficult compile (which it wasn't). As the only place I have ever downloaded a binary version is in Windows (where I lack a devel environment), I think it is quite likely that a user installing from source might be a first time user. XEmacs has a nice package management system. Few non-OS programs have anything nearly as easy to use. I found it kind of amusing that xemacs' package management system wouldn't work without first circumventing the manager to install its dependencies. That almost obviates the ease of use advantage that xemacs gets from the package management system. I don't really understand how it is decided what should be in core xemacs, and what should be in packages. Particularly, I don't understand why xemacs-base is separate from xemacs core. It looks (at first glance; I haven't been able to locate any documentation for the package) like a non-cohesive collection of utilities, for everything from the debugger to association list modification. In short, it looks like a random collection of files for xemacs' core lisp directory. Why are these separate? I noticed on the xemacs website, under SUMO integration, Stephen Turnbull wrote: I'd actually like to see more and more stuff pushed *out* of the core (but that is controversial). However, especially with well-maintained packages like dired and EFS, I think it makes a lot of sense to keep them separate. I'm curious; why would it be good if more files were pushed out of core? Is it easier to maintain packages when they are not in xemacs core? Or is this simply a concern for the size of xemacs on disk? nice to include efs and xemacs-base in the same tarball that the source comes in. If it's advantageous to keep them separate packages, they could be shipped that way, and a couple of lines in the Makefile could install them without an additional download and unpacking step. That way, xemacs can download additional packages easily, without any manual work. Sincerely, Byrel <http://www.us.xemacs.org/Releases/Public-21.2/execution.html#sumo> _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On Thu, Aug 4, 2011 at 8:05 PM, Eric S. Johansson <esj(a)harvee.org&gt; wrote: I wasn't really clear here. I use two OSes, Windows and Linux, but my preference is Linux. So, when I said that I use binary installs only in Windows, I meant that I usually use source, on Linux. I have yet to make a package manager work. I'm sure it is very nice but the Tools menu. I was impressed by how easy it was to use. Sincerely, Byrel _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Byrel Mitchell writes: This has long been a sore point with new users, but most new users nowadays use OS package managers or (on Windows) the standalone installer. To be frank, I don't consider new users who don't get over that hump worth spending much of my time on. They simply do not contribute back to the project anyway, mostly not even useful bug reports. "It's too much trouble." (Where have I heard that before? Oh, yeah, when you were installing XEmacs in the first place, eh?) Certainly, folks like Alan Mackenzie (CC Mode maintainer) also report annoyance with it, and I'd like to address their needs as much as possible. But I suspect Alan would prefer that I work on fixing the syntax cache bugs. I don't object to serving new users who just want to install XEmacs and never think about it again. And there are plenty of folks in between, who are frustrated by the initial install issues, maybe sufficiently so that we do lose contributions. I just don't think the loss to XEmacs from placing low priority on that compares to the cost in terms of time that could be spent on other development needs or on releases. Steve Baur decided that. But he passed away in February, so we can't ask him any more. I suspect that basically it's stuff that used to be in the lisp/prim (for "primitives") subdirectory, that didn't have an obvious place to go and wasn't needed for building XEmacs proper. I do know that one of his goals was what the extreme programming crowd later labelled "DRY". Most serious language projects maintain several stable versions of their product (eg, Python currently has *six*, GCC has at least 3) for years, giving them varying degrees of attention as they age. Emacs, on the other hand, only has *one*, and the users and 3rd party developers are expected to pay the price of backward incompatibility. We can't afford to do the former for a GNU Emacs-sized distribution, and as a in-the-trenches software professional, Steve did not want to settle for the Emacs style either.[1] So a small core supporting separate packages (mostly externally maintained), each with its own -- mostly independent -- development cycle, was a central goal. It constrains XEmacs to be backward compatible, and enforces modularity. I believe it does make those libraries easier to maintain and create, at the expense of making it harder to add features to the core. Feel free to populate the etc/bundled-packages directory in recent 21.5 and provide the necessary Makefile scaffolding. I haven't had time to think about how to deal with the problem of *where* to install those packages (or even *whether*, for people who already have packages installed). I think you will find that "a couple of lines in the Makefile" is insufficient for supporting the wide variety of systems out there. You're also going to need to deal with the tarpit of configure.ac. OTOH, maybe it will be a lot easier than I think. :-) Footnotes: [1] Later, when working for Cisco in 2007-2010, he fond himself supporting no less than 7 corporate-approved versions of Emacs and XEmacs. He said it was often quite annoying that he had to deal with minor variations in APIs for GNU Emacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta