[Pkg-octave-devel] Changes in emacsen policies
tweber at debian.org
Thu Jan 23 12:42:05 UTC 2014
On Thu, Jan 23, 2014 at 09:13:53AM +0100, Thomas Weber wrote:
> 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.
From: Rob Browning <rlb at defaultvalue.org>
To: Modestas Vainius <modax at debian.org>
Date: Wed, 22 Jan 2014 11:50:37 -0600
Subject: Re: Proposed new requirements for emacsen add-on packages
[Apologies for any duplication: resending because the previous cc list
had been truncated.]
Modestas Vainius <modax at debian.org> writes:
> I suggest that you bump policy version to 3 since current policy is probably
> going to be nothing like v2.
We could, though I hadn't been planning on it since these changes only
fix the current policy to work as I'd originally intended
(i.e. correctly). I think the 2.* policy before these changes is likely
Along those same lines, I wasn't planning to change the compat version
requirement (i.e. from 0 to 1) because at the moment, I haven't thought
of any way that would help us -- i.e. I can't think of any decisions
that emacsen-common could make that would help, based on that number.
> However, it's really unfortunate that emacsen-common dependency is needed
> again. I know nothing about emacsen-common internals but it's kind of weird
> that the problem cannot be solved with dpkg triggers.
I'm not sure if I already mentioned it here, but I'm not opposed to
triggers. Though if we made a change that substantial, we probably
*would* want to move to emacsen-common 3.*.
The problem I have with triggers to date is that I haven't yet been able
to convince myself that they're flexible enough to handle all of our
(potential) cases. For example, with triggers, can we arrange it so
that every add-on (or flavor) gets a chance to "remove" itself while
still fully configured? And if not, do we think that we can change
policy in a way that will still accommodate the needs of all add-ons
(i.e. would some kind of generic removal be sufficient in all cases)?
Another question -- assuming triggers run "later", can all all-on
packages be adjusted to behave "sanely enough" in the window between
when they're postinst fires, and when the triggers eventually run?
> In my cmake case, the package just ships syntax highlighting for emacs
> and some users have complained about cmake pulling in anything emacs
> related just because of this.
Understood -- one of the main points of 2.* was to remove the
dependencies, but it looks like that just may not be workable with the
current strategy (though I'd be happy to figure out I'm wrong). That
said, an emacsen-common dependency should still be much better than what
we required before, since emacsen-common is vastly smaller than any of
Ideally, the dependency requirement, assuming we decide that it's
necessary, will turn out to be a temporary addition -- until we figure
out how to remove it again (perhaps with triggers, or some other
But in the very short term, I'm just hoping to unbreak 2.*.
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
More information about the Pkg-octave-devel