Re: emacs mode for running debuild, debc, and debi etc.

[Rob Browning <rlb@defaultvalue.org>]

Steve Greenland <steveg@moregruel.net> writes:

>> If it's a big deal, then I can see about reviewing the code/policy to
>> check if it might be OK to allow add-on packages to depend on
>> emacsen-common directly.  For now, I'd continue to recommend against
>> that.
>
> I think this is worth doing. My simple mind imagines that things
> should work like this:
>
>     The packages containing elisp should look for one or more emacsen to
>     byte-compile with, and not worry if doesn't find any. If an emacs
>     (Gnu, X, whatever) is later installed, it should byte-compile any
>     installed elisps it finds.
>
> In fact, I thought that the whole point of emacsen-common was to support
> such usage.

Actually the main point was to support multiple simultaneously
installed versions of emacs and arrange things so that you safely end
up with properly built byte-code, etc. for each installed flavor for
all the add-on packages without having to bloat the archives with
per-emacs-flavor add-on binary packages.

> Now, if the package is *only* elisp, then a dependency is
> appropriate. But requiring every package that contains a single
> little emacs helper interface to its main functionality to depend on
> emacs seems like overkill.

Right, that falls under the "dont' do that then" category :> If you
only have a tiny bit of elisp, you either decide you don't need to
byte compile it, or you break it out as a separate equally tiny
package.  The rule is that you only need to depend on emacsen if you
need to use the emacsen-common infrastructure, and then, you *must*.

I don't doubt that we might be able to make things better, but here
are some further bits (edited), from my discussion with Santiago in
Feb that might prove informational:

  I suspect we might be able to fix this cleanly, but it may take some
  discussion.  Speaking entirely off the top of my head, I was wondering
  if we might be able to:

    * relax policy so that all the add-on packages don't have to depend
      on anything, and (as debhelper already does -- against policy ATM)
      allow packages to test for the emacsen-common scripts and only run
      them if they exist.

    * modify the emacsen-common install scripts so that if they're run
      before emacsen-common is configured, they do nothing.

    * make sure that the emacsen flavor packages (emacs20, xemacs20,
      etc.) run the full package install/remove set.  I think they do
      already, but we'd want to review the possibilities to make sure
      that you can't ever end up in a state where an add-on is left with
      some flavor of emacs installed, but isn't set up properly for that
      flavor, or an add-on is left with no flavor of emacs installed,
      but isn't cleaned up properly for that flavor.

  *If* we can make these assurances, I think we'd be OK, but we need
  to think through the cases.  In the case of emacs21 and gettext
  being installed at the same time, if gettext were configured before
  emacsen-common, its invocation of the install scripts would do
  nothing b/c emacsen-common isn't ready yet (the script would know
  this), but later when emacs21's postinst fires, gettext's emacsen
  install script would run.

  However, there's still a problem here -- what happens if
  emacsen-common is configured, then gettext, then emacs21?  When
  gettext's emacsen-common install script fires, it doesn't know that
  emacs21 isn't finished configuring yet :<

  All of this is why we made the original policy restrictions we did.
  Most of the solutions involve second guessing dpkg and the
  installation process, and seemed somewhat complex and likely to be
  fragile, and most seemed to be trying to re-implement things dpkg is
  intended to handle.

  However, we sill might be able to get things to work if we made
  policy a little more complex, and if I can get the time, I'd be
  willing to try.  As an improvement to the above, perhaps we could
  add some requirement (if we can figure out a mechanism) for the
  emacsen packages to note that they're in the process of configuring
  i.e.:

    # required in emacs21 preinst:
    rm /var/lib/emacsen-common/state/emacs21/*
    touch /var/lib/emacsen-common/state/emacs21/installing

    # required in emacs21 postinst:
    rm /var/lib/emacsen-common/state/emacs21/*
    touch /var/lib/emacsen-common/state/emacs21/installed

  and then emacsen-common's scripts can use this to determine when (not)
  to do anything.  However I suspect that there may be race conditions
  here we'll have to consider...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD