Re: An example Emacsen policy
(OK, I'm trying to refresh myself with respect to all of the policy
related issues and constraints, so bear with me...)
David Kastrup <dak@gnu.org> writes:
> While the unilateral chorus of Debian developers states that the
> current state of the Debian policy is perfect and can't be improved
> at all, I'd like to see the less perfect people upstream catered
> for.
Actually it's not unilateral. I'd be interested in improvements,
presuming:
- we can come up with improvements that really are improvements (and
not just churn). Even though it can probably be improved, the
current policy has functioned for quite a long time now, has a
large legacy of installed systems, and accomodates some fairly
complex requirements.
- we can be certain that these improvements will work at least as
well as current policy has, and by work, I mean stability across
Debian releases, no breakage across upgrades if policy is
followed, no race conditions for manual dpkg -i installs, etc.
- we have the manpower and and to manage any awkward transitions
So I'm willing to entertain suggested improvements, but I'd prefer
that everyone making suggestions make sure they've done at least some
of the following:
- carefully read the current policy (though I know the text needs
cleaning up)
- examine the current emacsen-common package's scripts (including
the DEBIAN/ scripts)
- perhaps look at the archives from back when we were devising this
policy (if they're still available -- I imagine these were on
debian-devel).
Of course I realize that (especially the last) is probably asking too
much, but I hope people will do what they can to make sure they
understand the issues, and of course I can try to help with context
and rationale where appropriate.
> a) XEmacs has a package system of its own. The stuff in that
> package tree has a structure distinctly different from the stuff in
> Emacs Lisp trees. For that reasons, it does not seem feasible to
> install common Emacs packages into the package tree of XEmacs.
What is the actual problem here? Can you give (or re-iterate) a small
concrete example?
One of the goals of the policy was to make it so that there was a
place where you could install files/packages that were emacsen
independent, but where you also had a place to install packages that
were specific to a particular emacsen flavor (say emacs21, xemacs21,
etc.). The version specific installs should take precedence over the
non-version specific installs, and any /usr/local/ installs
(i.e. administrator customizations) should take precedence over
anything else. See Policy(9) for info. This is also why add-on
packages aren't supposed to modify the load-path themselves --
emacsen-common ensures load-path ordering via
deban-pkg-add-load-path-item -- i.e. so an add-on package doesn't
override /usr/local.
One thing I don't think we considered, was a place for things that
were intended only for *any* emacs or *any* xemacs. i.e. we didn't
mandate /usr/share/{emacs,xemacs}/site-lisp directories. Offhand, I
don't see any reason why we couldn't if this would be helpful.
I *do* think we should keep a common directory for flavor independent
upstream or debian-specific files that a maintainer might want to
provide. i.e. (setq my-debian-specific-package-version "4").
Also, I'm not sure I yet fully understand the complaints about
share/.../site-lisp on the xemacs side, but I belive we were just
following broader Debian policy, i.e. the FHS says that architecture
independent files go in *share*, not lib. Debian maintainers are
supposed to modify packages that don't follow the FHS.
> b) some stuff is provided in the XEmacs sumo tar ball. As a rule,
> stuff in the sumo tar ball is older than what might be provided as a
> common Emacs package.
>
> c) the current "do it the Debian way or else" is not suitable for
> letting people play around with developer versions, or let developers
> play with Debian packages.
So what are the specific problems here (perhaps that's what's below)?
> If Debian is not a completely different world from standard
> compilations of Emacs/XEmacs, this will be helpful.
I belive the intention has always been to support local overrides.
The current mechanisms for that are intended to be the
/etc/emacs/site-start.el and the /usr/local/... paths, and anything
the local admin places here should always take precedence.
> So what are things that I would want to have different?
>
> a) .el files and corresponding .elc files need to be in the same
> directory. This is the way paths and path searching and byte
> compilation are organized in Emacs and XEmacs, and quite a bit of code
> relies on it.
This makes sense, though the question is whether or not we can design
a reasonable alternative to the current practice and not break
backward compatibility unacceptably during any transition. If this
does need to be done, I'd like to figure out the minimal set of
changes that will accomplish it.
Also, given the current policy, off the top of my head, I suspect any
package that wanted to could store its .el files in
/usr/share/PACKAGE/ and symlink or copy them into the relevant
site-lisp dirs during the emacsen install. I suppose if we work out
the details, and the solution turned out to be good, we could make
that a default policy recommendation.
> soft links might not work when exporting just a specific Emacs tree
> (though this might be manageable with suitable export options).
Can you explain the problem you see with soft links a bit more?
> c) the XEmacs package system requires packages to be in a rather
> specific format, and with precompiled Lisp files. Generic Elisp
> packages will not usually be in that format. For that reason, generic
> Debian Elisp packages will not install into an XEmacs package tree.
Can you elaborate on what you mean? What if a "generic Debian elisp
package" really is generic, i.e. it's code will execute without
problems in xmacs? Or do you mean something more specific by
"package" here than possibly just a "subtree of elisp code" that
should be available in the load-path? (I'm not familiar with xemacs
packages.)
One of the original goals of Debian Emacs Policy was to avoid shipping
.elc files for every flavor of emacs. This was assumed to represent
quite a bit of potential archive mirror bloat.
There's may also be a compatibility issue. If the given package
depends on other elisp packages, and those packages change
(i.e. imagine their public macros change), then you must recompile
anyway. Package dependencies won't help you here unless every emacs
is going to add conflicts with the set of add-on packages when it
comes out.
Also since we don't *know* that upstream won't change binary elc
compatibility during a stable series, we tried to be conservative. If
add-on packages do choose to byte compile with every install (or
whenever they detect that they need to), then there's no problem, and
the emacsen maintainers don't have to worry about what's going on in
all the add-on packages.
So although add-on packages aren't required to byte-compile in their
emacsen-common install/remove scripts (or do much else for that
matter), doing so avoids these problems.
The current emacsen-common infrastructure allows the add-on package
maintainer a great deal of flexibility when deciding how to handle
these issues.
> d) an XEmacs-specific Debian package should shadow a generic
> epackage.
Hmm. I was under the assumption that this should already be true if
everyone's following current policy. Perhaps I'm misremembering.
And according to current policy, /usr/local/* i.e. the local admin's
stuff, should shadow anything else.
> user-specific site-lisp
> user-specific XEmacs packages (something like ~/.xemacs-packages)
Why do we need this? This is the user's domain. i.e. can't they just
modify the load-path (or whatever's needed) in their .elisp file if
they like?
> debian-packages for XEmacs package tree (/usr/share/xemacs21/site-packages)
> debian-packages for generic Elisp trees (/usr/share/xemacs21/site-lisp)
I'd like to know a bit more about the requirements for xemacs
packages. Can their needs not be satisfied by (whatever) suitable
code in
/etc/FLAVOR/site-start.d/PACKAGE
Note too that as mentioned, there's no reason that any package *has*
to byte compile (or do anything else) in the emacsen-common install
script, though it does avoid some of the problems mentioned above.
> complete misnomer since it holds a site-specific choice of packages
> added to (or overriding) the basic XEmacs tree. Still, it might be an
> idea to name it dist-* or similar to avoid having the user tamper with
> that tree.
It is well established Debian Policy that the user should *never*
tamper with anything outside specific dirs like /etc, home, and
/usr/local. So this is already fully documented -- /usr/share is
off-limits.
> mkdir /usr/share/emacsen/flavors/emacs-unicode
> cd /usr/share/emacsen/flavors/emacs-unicode
> ln -s /usr/local/emacs-unicode/share/emacs/site-lisp .
> ln -s /usr/local/emacs-unicode/bin/emacs .
> ln -s ../../auctex .
If I understand what you mean correctly, this is just not allowed, and
is not going to be supported. If the user wants this, they should be
using /usr/local, or their own homedir, and we should make sure that
works right. The admin/user is never supposed to mess with /usr/share
directly on a Debian system.
One other thing I've been meaning to look in to is how modern
emacsen's directory scanning fits in (subdirs.el?). Is this relevant
to us?
(NB: I was kind of in a hurry when writing this, so there may be some
mistakes.)
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: