Title pui should be more aggressive about installing required packages
Type feature Module core code 21.4, core code 21.5
Severity inconvenience Platform N/A
Keywords Nosy List mike.kupfer
These controls should only be changed by committers and tracker administrators.
Status verified   Reason
Priority normal   Assigned To

Created on 2009-06-19.02:13:21 by mike.kupfer, last changed 2009-07-31.16:16:02 by FKtPp.

msg1790 [hidden] ([hidden]) Date: 2009-07-31.16:16:02
  Message-ID: <>
It's not very easy for a user to recover from a missing package except
he knows there's a #'package-get-package-provider command
msg1260 [hidden] ([hidden]) Date: 2009-07-01.17:26:41
A followup comment on the severity: I had filed it as "some work
obstructed" thinking it might be difficult for newbies to recover from
a missing package.  But it occurs to me that such users probably get
XEmacs from a distro provider (e.g., Ubuntu), and they're likely to
already have all the packages from the sumo.  Users who are
sophisticated enough to set up and run XEmacs on their own are
probably sophisticated enough to recover from a missing package.
msg1240 [hidden] ([hidden]) Date: 2009-07-01.10:30:03
  Message-ID: <>
Unfortunately, the dependency PUI knows about is *build time*.  This means that 
packages which are required only for macros would get pulled in, but macros are not 
(cannot be) called from compiled code (eg, cl-macs.el).  Second, maintainers are on 
their honor to put packages which supply autoloaded functions into the list of 
REQUIRES in the Makefile; there is no way to force this.  So there's no guarantee 
that the set of packages in REQUIRES is accurate in either direction.

Furthermore, in many cases the requirement is for an unusual case that most users 
don't care about.

IMO, the right solution is to add a backend to the byte-compiler which does nothing 
except maintain a database of functions and variables and their sources for use in 
generating a list of run-time dependencies.  But even then you run into the problem 
that people who actually want a lean-and-mean XEmacs (hah!) would have to work 
around PUI trying to require packages that they personally don't need.

The preferred workaround for now is to just recommend installing the SUMOs.  Third 
party packagers should just install the SUMOs, too.

A patch to make PUI issue a warning if there are packages selected with unsatisfied 
dependencies would be accepted, I think.  A patch to automatically select 
dependencies would not, I believe (I'd be -0.3 or so on it).
msg1221 [hidden] ([hidden]) Date: 2009-06-19.02:13:21
Suppose you have two packages, A and B.  Neither is installed, and A
requires B.  

If the user selects A to install, she can then type "r".  PUI will
list B and give her the option of installing it as well.  But unlike
the OS package managers that I'm familiar with (Synaptic, the YaST
package front-end, and the OpenSolaris package manager), the user must
ask for this check; it's not done automatically.

This probably isn't a big deal for experienced users, but it could be
a problem for newbies: it's an extra manual step, and if B doesn't get
installed, it might not be clear from A's error message that that's
what the problem is.
Date User Action Args
2009-07-31 16:16:02FKtPpsetmessages: + msg1790
2009-07-01 17:26:41mike.kupfersetmessages: + msg1260
2009-07-01 10:30:03stephensetstatus: new -> verified
messages: + msg1240
severity: some work obstructed -> inconvenience
2009-06-19 02:13:21mike.kupfercreate