[Pkg-emacsen-addons] htmlize.el and elpa-muse/muse-el

[Nicholas D Steeves]

Hi Sean and David,

On Fri, Sep 02, 2016 at 06:49:01PM -0700, Sean Whitton wrote:
> Hello Nicholas,
> 
> On Fri, Sep 02, 2016 at 06:33:37PM -0400, Nicholas D Steeves wrote:
> > > I don't see any bug in dh_elpa here.  Could you explain what you were
> > > expecting dh_elpa to do that it isn't doing?
> > 
> > In #debian-emacs David found no problems installing to sid—no patch
> > needed, so I installed stretch/testing on an ancient laptop I keep
> > around as an emergency backup.  It pulled in htmlize from
> > emacs-goodies-el, and everything was fine.  If org-mode is already
> > installed, htmlize.el from goodies is used, presumably because
> > emacs-goodies alphabetically precedes org-mode.
> > 
> > In testing your experimental dh-elpa bpo with my experimental
> > elpa-muse bpo, I found that using the emacs24 bpo yielded a successful
> > configuration.
> > 
> > In light of this, when you backport dh-elpa for magit2 ;-), please
> > make it depend on a minimum version of emacs 24.5+1-6~bpo8+1.
> 
> I take it you mean that the backported dh_elpa should *generate*
> dependencies on emacs 24.5?  I'd be interested to hear others' opinions,
> and maybe I've misunderstood the issue, but I don't think that's the
> right thing to do.

I meant a change of dh-elpa/debian/control:

- emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
+ emacs24-nox | emacs24 (>>24.4) | emacs24-lucid (>>24.4),

or similar, so that it would be fulfilled by 24.5+1-6~bpo8+1 and not
24.4+1-5 in jessie.  If elpafied *-el modules are being tested with
emacs 24.5, then using them with emacs 24.4 is less well-tested case
that is more likely to cause bizarre and/or undefined behaviour.

By generate, you mean that the bytecompiled code dh-elpa generates
during the configuration of an elpafied package would depend on a
specific emacs version?  I assumed that functionality was already
implemented.

> It seems like the problem is with the one of the various htmlize
> versions floating about.  The problem is not in dh_elpa, so far as I can
> tell.  So it seems that the fix should go into the package that needs
> htmlize (muse) or one of the packages providing it.
> 
> -- 
> Sean Whitton

After more analysis, I've found that there are two issues:

First, yes, I now agree with Sean that various htmlize.el versions are
an issue.  For example, with Stretch, elpified muse-el install
succeeds with emacs-goodies-el (htmlize v1.43), or with both goodies
and org-mode installed--presumably because it uses emacs-goodies-el
verson.  It does not install with just org-mode (htmlize v1.36). <
http://paste.debian.net/805668/ > This seems to indicate that at some
point htmlize became backwards-incompatible...  I tested this locally
by removing both goodies and org-mode from muse-el's debian/control
and running an a vs b vs a+b series of tests, with 'apt-get purge
emacs-goodies-el org-mode' in between tests.

For Stretch, A+b works for now, but if ever there is a package called
"apple-pie-el" that provides htmlize.el >1.36, I suspect the
bytecompiling phase of configuring some packages will fail.  Would it
be sensible to unbundle htmlize.el from all package that provide it
and create a htmlize-el package, and then validate the reverse
dependencies?  Whatever direction things go, I know I'm responsible to
make muse-el work! :-) Even if a future apple-pie-el is uploaded that
forces a new fix...

The second issue was that a local bpo of elpa-muse failed
bytecompiling/configuration with emacs 24.4 (jessie) but not emacs
24.5 (jessie-backports), with certain configurations.  After two
series of the same a, b, a+b htmlize.el compatibility tests (one
series for emacs 24.4 and one for 24.5) I found that that a+b tests
for emacs-24.4 failed, but succeeded with emacs-24.5.  Emacs 24.4 +
dh-elpa bpo + elpa-muse bpo + emacs-goodies-el AND org-mode fails, BUT
with the emacs 24.5 bpo this a+b configuration succeeds.  This seems
to indicate that elpafication is more likely to succeed with emacs
24.5...but that's not a concern for sid. ;-) Maybe the a+b order gets
inverted to b+a with emacs 24.4?

At any rate, these experiments have definitely made it clear how
multiple bundled libraries with non-specific scope (eg: bundles in
/opt with bundled libraries that are not available to other programs)
can cause headaches.

To unbundle htmlize.el from all packages that provided it and
centralise it to pkg:htmlize-el, is this an example of a Debian
"transition"?

By the way Sean, the only reason I suspected a dh-elpa issue is
because on IRC you said I had found a bug!  I've been running these
test-cases because I wanted to deductively eliminate that as a cause,
because I generally prefer issues in the category of "things I can
fix" vs "things I need to depend on someone else to fix" ;-)

    Re: < spwhitton> nick[0]: I don't like the idea of adding that
    dependency just wrong.  If there is a problem with htmlize it
    should be fixed provides htmlize or the package
    using it.  It's not a general fix.

Do you mean that instead of a worst-case scenario of disabling htmlize
functionality in muse-el I bundle a "known good" htmlize.el with the
package?  That is definitely the other direction things can go, to
eliminate unpredictable results--where each extra emacs mode bundles
its own known good copy of version-sensitive dependencies.  I don't
have the experience to know when one way is more beneficial, so I'll
go with whatever you guys decide.

Cheers,
Nicholas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-emacsen-addons/attachments/20160903/9a33c67c/attachment.sig>