Rob Browning <r...@defaultvalue.org> writes:
> 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.
So squeeze has been released, and I'm finally back to work on this. I
expect to have a prototype emacsen-common fairly soon which will work
more or less as described above.
I'm trying to arrange it so that add-on packages won't be required to
have dependencies on any emacs flavors or on emacsen-common (though they
will need an emacsen-common << VER conflict). Emacs flavors will only
be required to depend on emacsen-common (>= ...). Of course add-on
packages will still have to depend on other relevant packages, perhaps
including other add-ons.
Here's a quick, rough summary of what's currently planned for the
various install/remove steps (below, "ec" == emacsen-common). For the
most part, only one or two lines of code will be required in each
script. Please let me know if you see potential problems.
What's actually required for emacsen flavors (emacs23, xemacs21, ...):
preinst:
/usr/lib/emacsen-common/emacs-install --preinst FLAVOR
postinst:
/usr/lib/emacsen-common/emacs-install --postinst FLAVOR
prerm:
/usr/lib/emacsen-common/emacs-remove --prerm FLAVOR
What's actually required for add-on packages (bbdb, auctex, ...):
preinst:
if test -e /var/lib/ec/state/package/installed/emacsen-common
/usr/lib/emacsen-common/emacs-package-install --preinst PACKAGE
postinst:
if test -e /var/lib/ec/state/package/installed/emacsen-common
/usr/lib/emacsen-common/emacs-package-install --postinst PACKAGE
prerm:
if test -e /var/lib/ec/state/package/installed/emacsen-common
/usr/lib/emacsen-common/emacs-package-remove --prerm PACKAGE
What actually happens for emacsen flavors (emacs23, xemacs21, ...):
preinst:
rm -f /var/lib/ec/state/flavor/installed/FLAVOR
postinst:
for dependency ordered pkg in /var/lib/ec/state/package/installed/*
/usr/lib/emacsen-common/packages/install/$pkg FLAVOR
touch /var/lib/ec/state/flavor/installed/FLAVOR
prerm:
for reverse dependency ordered pkg in /var/lib/ec/state/package/installed/*
/usr/lib/emacsen-common/packages/remove/$pkg FLAVOR
rm -f /var/lib/ec/state/flavor/installed/FLAVOR
What actually happens for add-on packages (bbdb, auctex, ...):
preinst:
rm -f /var/lib/ec/state/package/installed/PACKAGE
postinst:
for flavor in /var/lib/ec/state/flavor/installed/*
/usr/lib/emacsen-common/packages/install/PACKAGE $flavor
touch /var/lib/ec/state/package/installed/PACKAGE
prerm:
rm -f /var/lib/ec/state/package/installed/PACKAGE
for flavor in /var/lib/ec/state/flavor/installed/*
/usr/lib/emacsen-common/packages/install/PACKAGE $flavor
Questions:
- This process drops the generic "emacs" flavor, and only passes the
current flavor when calling the package install/remove scripts. For
reference, see the section in current policy that mentions this:
/usr/lib/emacsen-common/packages/install/foo emacs emacs23 xemacs21
/usr/lib/emacsen-common/packages/install/foo emacs23 emacs23 xemacs21
/usr/lib/emacsen-common/packages/install/foo xemacs21 emacs23 xemacs21
The new approach is simpler -- is it sufficient?
- In my original plan, I'd considered adding another state file:
.../installing/{PACKAGE,FLAVOR}. I imagine I had a reason, but I
can't recall what it was. Does anyone see any corner cases that
might require it?
- Right now an add-on is either installed or not installed. It would
be possible to support per-flavor installation states instead.
I'd rather not, but would it provide any benefit?
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
--
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/87fwpix9fk....@raven.defaultvalue.org
