[Debichem-devel] Proposed new requirements for emacsen add-on packages

[Rob Browning]

[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
just broken.

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
the flavors.

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
approach).

But in the very short term, I'm just hoping to unbreak 2.*.

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