Re: RFC: relaxation of debian-emacs-policy dependency requirements
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency requirements"):
>> After some investigation, it looks like we might be able to change
>> policy to just require add-on packages to depend on emacsen-common,
>> which is reasonably small, ~150k, and could probably become smaller if
>> necessary.
>
> Why should a package which happens to also ship some elisp need to
> depend on any Emacs package at all ? What will go wrong if the
> package is installed without any Emacs ?
If the package doesn't need to use any of the emacsen-common build
infrastructure (doesn't need to byte-compile for each flavor, etc.),
then it doesn't need to have any emacsen-related dependencies -- that's
already in policy.
For packages that do need to use the infrastructure, I believe the
original intent was to make sure that an add-on package couldn't start
using emacsen-common before it was fully configured. It may be possible
to re-write emacsen-common to change that requirement, but I'm not
certain offhand.
If we do want to try to eliminate that requirement, there are a number
of important constraints (which are also open for discussion):
- Any time an add-on package is installed or upgraded, it should be
automatically "built" (whatever that means, but it usually means
byte-compilation) for every installed flavor of emacs.
- Any time a flavor of emacs is installed or upgraded, every
*fully-installed*[1] add-on package should be automatically
(re)built for that flavor of emacs in an order that respects any
inter-add-on-package dependencies (i.e. say auctex "Depends:
foo-el"). Currently this ordering is handled manually via tsort
from the emacs-install script.
- Every time an emacs flavor is removed, all of the add-ons should
clean themselves up with respect to that flavor.
- Every time an add-on package is removed, it should clean itself up
with respect to every installed flavor of emacs.
- If some collection of add-on packages and some collection of flavors
of emacs are installed in the same dpkg run, the "right thing"
should happen, no matter the order in which dpkg decides to handle them.
- Ideally, there should be no redundant add-on package builds, but
right now, there may be. Imagine "apt-get install auctex emacs23"
At the moment, I believe auctex will be built twice.
- Add-on packages should not be built before all of their package
dependencies are installed[1], including non-emacs-related deps. This
is currently a problem -- imagine an "apt-get install emacs21 auctex"
where auctex depends on gs and gs (or a gs provider) isn't installed.
If auctex doesn't depend on emacs21, and dpkg installs emacs21 first,
such that emacs21's postinst goes first, that postinst may call
auctex's emasen-common install script to build it when gs isn't
available. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370672). The
"Depends: foo-el" mentioned above provides a similar problem.
I brought up this RFC because lately I've been trying to determine how
we might be able to improve the current situation, and I've been
learning about triggers to see if they might help. So far, I just know
that triggers can't help with add-on removal since they fire after the
add-on package has been removed.
[1] Right now if you install several add-ons along with an emacs flavor,
even if the emacs postinst fires in the "middle", it still will
treat all the add-ons as if they're installed, since emacs-install
just looks at the set of add-on install scripts (packages/install/*)
to decide what's available.
Barring something better, I believe we might be able to fix this by
maintaining appropriate state files like
/var/lib/emacsen-common/state/package/installing/FOO from the add-on
preinst/postinst, or similar.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: