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

[Rob Browning]

Agustin Martin <agmartin at debian.org> writes:

> I may be wrong, but if add-on-depending-on-add-on-1 depends on add-on-1 dpkg
> should care of configuring add-on-1 first. However, there is no warranty
> about unpack ordering.

No, of course -- I think you're right, and I believe that was part of my
reasoning when working on the 2.* system originally.  I think I just got
caught up second-guessing the earlier work.

So I suppose the short-term question is, assuming we do add the
emacsen-common dependency, are there still any significantly broken
cases?  i.e. do we have to have a major overhaul in the short-term, or
would the dependency be sufficient?  I'll give it some further thought,
but would definitely appreciate some additional evaluations/opinions.

And I'd like to ignore the "redundant install" issue for the moment,
since that's not a critical problem, just a potential waste of some
time -- though certainly worth fixing if/when we can.

> Some add-ons do a check to avoid that, check that .elc for last
> byte-compiled file is present. If so, it is already done, otherwise
> byte-compile. But is way better if is emacsen-common who cares about that.

Right, I'd originally expected that some packages might choose to be
"smarter", but I also wondered if there really was any safe definition
of smarter.

For example, to be conservative, should an add-on always rebuild?
i.e. if the install script is being invoked because a new version of
emacs24 is being installed, there's no way for the add-on to know
whether or not the new emacs24 includes bug-fixes for byte-compilation.

> I think you are right, they may be the best option, but some ellaboration is
> needed to properly evaluate that possibility, before going further into it.

Absolutely -- and first, I'd need to understand triggers a lot better.

> In a quick proposal, I'd think about emacs-install and emacs-package-install
> just touching action flags like

I'll have to reread this bit after I've studied triggers more carefully.

> Note however that if depends is the way to go, you will have to handle
> this depends with a lot of maintainers with very different
> responsiveness maintaining add-ons with very different complexity and
> userbase.

Agreed, though perhaps this would be a simple enough change (just the
dep -- though the other cleanups the dep allows would be nice) that NMUs
could be used in cases where the maintainer isn't able to get to it
soonish.

Currently I'm inclined to think that if we can convince ourselves that
adding the dependency will more or less "fix" things for "new-style"
packages, then that may be the right thing to do for now, since the
alternative appears to be a much bigger overhaul -- an overhaul that I
suspect in the end may well require even more substantial changes to all
add-on packages.

Many thanks for helping me think this through.
-- 
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