"Vin Shelton" <acs(a)xemacs.org&gt; writes: I agree. Specifically, the packages shouldn't have any specific version of XEmacs encoded in the path. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

APA> That would be my preference too, taking Glynn's input into APA> account we should probably go with %ProgramFiles%\XEmacs XEmacs-21.4.19 XEmacs-21.5-b25 mule-packages site-packages xemacs-packages APA> I'm not in favor of more adventurous layouts based on the APA> fact that we lack experience with them. APA> I think we should cater to inexperienced users in the Windows APA> world, to give them one configuration that will just work. APA> More experienced users can allows help themselves. That's not always true. I haven't looked at the code in package-get/pui for a while, but at one point it was easily confused about when to dive into a package hierarchy and when to use a package directory. I don't think it's a good idea to have package hierarchies (like "xemacs-packages" in the layout above) as siblings to package directories (like "XEmacs" in the layout above). But that would be my natural inclination. -- School of Systems and Information Engineering 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.

vin> 1) The user shall be able to choose where the installed files vin> go. My question is how flexible is this going to be? On Unix we still have people who care about "share" vs "lib". As far as I can tell, that's not true on Windows, so there's no harm in insisting that there be a single XEmacs root under which you can find all of XEmacs's system files, presumably grouped into version-specific core installations and (a) package installation(s). I think it's enough to allow the user to choose that root. Under that, the installation should allow multiple installations of both core and package distributions (presumably rare, but see below for a use case), but in fixed relative positions. vin> 2) Multiple installations shll be able to share package vin> installations. (I would prefer to do this without requiring vin> EMACSPACKAGEPATH, which will be an install/documentation vin> encumbrance.) vin> These requirements are why I want to install into (by default): vin> C:\Program Files\XEmacs vin> XEmacs-21.4.19 vin> XEmacs-21.5-b25 vin> mule-packages vin> site-packages vin> xemacs-packages I'd put in an additional level for packages, so that people could have C:\Program Files\XEmacs XEmacs-21.4.19 # what goes here? like this? etc i386-windows-nt info lisp XEmacs-21.5-b25 Lisp Packages mule-packages site-packages xemacs-packages Prerelease Packages mule-packages site-packages xemacs-packages where the package hierarchies under "Lisp Packages" would be found by default without special configuration or environment variables. Then everybody else must use something like EARLYPACKAGES="%HOME%\.xemacs;C:\Program Files\XEmacs\Prerelease Packages" (whatever the proper syntax is) to get an instance with prerelease packages in the path. (Of course AFAIK PUI doesn't support this kind of thing yet, but it would be nice if it did.) -- School of Systems and Information Engineering 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.

vin> On 3/8/06, Stephen J. Turnbull <stephen(a)xemacs.org&gt; wrote: >> vin> I think we have distributors who care about "share" vs vin> "lib". Remember the Windows world is populated by people who vin> are used to getting their software pre-packaged for them. I'd really rather not think about that. Too depressing. ;-) vin> But I don't think we support the use case you specified, vin> except through EMACSPACKAGEPATH or EMACSLOADPATH. Do we? No, and we shouldn't support it without some such device. The case you have in mind, ie users with multiple core installations sharing a package installation, should be supported out of the box, with no extra effort on the user's part (if desired, across users, I hope). There are two good reasons for this: we provide multiple distributions, and a broken core is a total disaster for the user. But having multiple package installations is clearly an "advanced" usage, a convenience for people who know what they're doing and are doing it to help us. I don't think EMACSPACKAGEPATH is a terribly large obstacle for such users: they can script it, and sometimes the flexibility comes in handy. Users who have special needs with respect to packages can generally get the appropriate effect by installing their own versions in .xemacs. Prereleases might conflict with site or personal packages, so we really do need a third hierarchy for testing. Currently, we really only provide one distribution of the packages, intended to be stable. And if a package is broken, it can be fixed independently and more or less on the fly; no need to reinstall the whole package distribution. So I'd like to avoid unnecessary obstacles to multiple full package distributions, but I don't think we need to provide special support beyond the level of EMACSPACKAGEPATH. Note that the extra level of directory above *-packages may not be necessary; you could have the "standard" location for them be a sibling to XEmacs-%VERSION%. However, Prereleases/*-packages in the same place seems like a natural way to handle prereleases, and the package finding code has to take care not to recurse into it unless explicitly specified. Also, it would look nicer to have symmetry between the stable packages hierarchy and any auxiliary ones. I don't claim any of that is a terribly strong argument for the structure I proposed. I just happen to like that one, and those are the reasons why. :-) -- School of Systems and Information Engineering 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.