Re: RFC: relaxation of debian-emacs-policy dependency requirements

[Rob Browning <rlb@defaultvalue.org>]

Rob Browning <rlb@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