[ Followups redirected from xemacs-patches to xemacs-beta. ] greg(a)alphatech.com (Greg Klanderman) wrote: Could you please separate the code that grabs the new package-get-base.el into a separate function (in package-admin.el or package-get.el -- and not package-ui.el)? Reasons: * Sometimes you just want to update package-get-base.el. * People who access these functions via menu picks cannot specify a prefix (there's no way to specify a prefix using menu picks). We'll probably have to provide a separate (?) menu pick that updates package-get-base.el, and maybe yet-another-menu-pick (ugh) that updates package-get-base.el before entering the visual package installer. Dunno. I can think of reasons to do it, and reasons to not do it. This is fine for an interim (temporary) solution, but what we really need is for the installer to (optionally) auto-select all dependent packages (and make it stop automatically grabbing the dependent packages without telling the user). That way the user can see everything that will be installed, and he can then manually unselect anything that he doesn't want (with a suitable warning message when unselecting dependent packages). If this is done, we'd only have to call `package-get' instead of `package-get-all'. This feature needs to be added, but your implementation has potential problems: * The package install directory information needs to be managed by package-admin.el. It's best if all the directory information is maintained by one module. * Do we really want to allow installations into arbitrary directories (that is, ones which will NOT be located by XEmacs' automatic package path finder)? This is an issue for novice users. Personally, I think we should restrict package installations to specific "system" locations (e.g., to the package-paths specified at configure time) or to the user-local location ("~/.xemacs/packages"???). Creating a good user-interface for this is a pain, though, and so we might want to just settle for some kind of warning if the user enters a "bad" path. This sounds like a bug. Newer versions should never be overwritten with an older one (well, maybe we should provide yet another prefix arg/variable that forces an installation for advanced users). -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.