Rob Browning <r...@defaultvalue.org> writes:
> I'd be quite happy if we really can eliminate any need for add-on
> packages to depend on emacsen-common. The main objection I have to the
> use of installed-flavors is that it's an implementation detail (and one
> I've been thinking about changing), but I'm fine with adding an
> officially documented mechanism, one that we plan to support
> indefinitely, presuming it ends up being reasonable.
>
> As an example, and as I hinted, I've been wondering if we might be able
> to resolve some of the remaining problems by maintaining some stamp
> files from within emacsen-common, perhaps
>
> /var/lib/emacsen-common/state/package/installed/FOO
So I think I'm going to adjust the tree I've been hacking on to
implement this and see how it looks. Does anyone have any objections or
complaints?
Here's what I'm planning (more or less):
- Have a canonical state file (or state files) for every add-on,
including emacsen-common, probably .../installed/FOO and/or
installing/FOO.
- Require all packages to guard emacsen-common infrastructure calls
with something equivalent to "test -e .../installed/emacsen-common".
- Require all add-on packages to call "emacs-package-install --preinst
..." from their preinst.
- Require all add-on packages to specify --postinst when calling
emacs-package-install from their postinst. That will make it
possible to detect updated add-on packages.
- Require emacs flavors to call emacs-install with comparable
--postinst and --preinst arguments.
- Require all updated add-on packages and emacs flavors to declare a
"Conflicts: emacsen-common (<< UPDATED-EMACSEN-VERSION)".
I think this may allow us to remove the requirement that add-on packages
depend on emacs flavors, and may fix the bugs we've been discussing. It
may also make it possible to avoid some duplicate add-on package builds.
Thoughts?
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
--
To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hkswh5o....@raven.defaultvalue.org
