[Pkg-octave-devel] Changes in emacsen policies

[Thomas Weber]

On Thu, Jan 23, 2014 at 09:13:53AM +0100, Thomas Weber wrote:
> Hi, 
> there seems to be a change in the emacsen policy in the pipeline. We
> (package maintainer address) were cc'd in some emails, but I deleted
> them as moderator. This was an accident, but there were like 100 CC
> addresses, so I considered it spam without even looking at the content. 
> 
> I still have the *content* of these emails, which I will send as replies
> to this email.

Mail 2:
From: Rob Browning <rlb at defaultvalue.org>
To: Agustin Martin <agustin6martin at gmail.com>
Date: Wed, 22 Jan 2014 12:39:27 -0600
Subject: Re: Proposed new requirements for emacsen add-on packages

Agustin Martin <agustin6martin at gmail.com> writes:

> Did not test in depth, but I think the add-on state files state files
> could be recreated from /usr/lib/emacsen-common/packages/install in
> case emacsen-common is installed for the first time (i.e., not
> upgraded). Since emacs flavours depend on emacsen-common they should
> byte compile things when configured.

I may be misunderstanding, but if not, I think the problem there is
simultaneous installs (which are our primary complication in general),

i.e. most of the complexity we have comes from the fact that we're
operating outside dpkg's dependency system (to avoid add-on deps), and
so we have no ordering guarantees.

That's why I added the state/package/installed infrastructure, but I'm
beginning to think that this approach may just be insufficient.  The
original idea was that the state files would allow add-ons to signal
that they're "ready to go" with respect to emacsen-common install/remove
calls.

For example, consider the case where no emacsen-related packages are
installed and someone runs this:

  apt-get install emacs24 add-on-1

Because there are no relevant dpkg deps, the packages' maintainer
scripts can fire in any relative order, and if emacs24's postinst fires
before add-on-1's, it can know to skip installing add-on-1 because
package/installed/add-on-1 doesn't exist.  But emacs24 *will* create
flavor/installed/emacs24, so that when add-on-1's postinst fires, its
install script will be run for emacs24.  Of course, something reasonable
should also happen if the order is reversed.

However, to demonstrate why I'm beginning to think the current approach
may be unworkable, consider the case where no emacsen-related packages
are installed and someone runs this:

  apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1

What should happen if the postinsts fire in the order listed?  When
add-on-depending-on-add-on-1's postinst fires, add-on-1 isn't
"installed", and so add-on-depending-on-add-on-1 should be skipped
(though that may actually be broken right now), and then when add-on-1's
postinst fires, it's not (currently) going to do anything about the
other add-on because add-on-depending-on-add-on-1 isn't a dependency for
add-on-1.

I begin to suspect that up to now, we may have just been fairly lucky,
and that the current approach is may just be broken for any number of
cases like this.  And unfortunately, adding the emacsen-common
dependency won't help.

Another reason why I keep wondering about the possibility of using
triggers is that even if we addressed some of the above issues, the
current approach will still probably result in redundant installs from
time to time.  Even if you want to be conservative and expect to
reinstall an add-on whenever it's upgraded, or any flavor is upgraded,
consider the previous example, but assume that all of the packages are
already installed (just being upgraded):

  apt-get install emacs24 add-on-depending-on-add-on-1 add-on-1

Currently, the emacs24 postinst will install both of the add-ons, and
then each add-on will install itself, and add-on-depending-on-add-on-1
will also reinstall add-on-1 again.  With a triggers-based approach
you'd hope that we could coordinate better, and only run each install
once.

So, generally speaking, unless we come up with alternatives, I'm
beginning to wonder if triggers may be our best option, assuming we can
shoehorn all add-ons into accommodating the attendant restrictions
(whatever they end up being).

> If something like this does not work adding the dependency is the
> lesser evil as long as emacsen-common NEVER tries to pull emacsen nor
> anything that should not be present in a very minimal system. But I
> still prefer a fix into emacsen-common itself if possible.

Right -- if we go this way, I'd plan to keep emacsen-common very small,
and as independent as possible.

> Other interesting things were proposed in this thread like having
> support for things like
>
>  elfiles=foo.el bar.el autoload.el
>  . /usr/lib/emacsen-common/emacs-install-standard.sh
>
> but while highly desirable this is something different from the
> original problem this thread is about.

Agreed, and there are a number of ways we might manage something like
that, which might or might not involve the code going directly into
emacsen-common -- i.e. we might want a separate binary package that the
relevant add-ons could depend on.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4