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

[Sean Whitton]

Hello,

On Sat, Sep 03, 2016 at 12:24:58AM -0400, Nicholas D Steeves wrote:
> > 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.

No, I mean the contents of ${elpa:Depends}.

Since dh-elpa is not a dependency of elpa-foo, the dependency you
suggest wouldn't ensure that the correct version of emacs was available
when elpa-foo was installed.

You could just add a dependency on 24.5 on your backport of elpa-muse?
Would that be enough in the shot term?

> 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?

Yes.

> 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"?

You could call it a transition but it's not the kind of thing that needs
a release team transition tracker, if that's what you were referring to.

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

I think you mis-quoted me since that sentence isn't grammatical ;)

I think it would be bad to introduce another htmlize.el to the archive.

Thanks!

-- 
Sean Whitton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-emacsen-addons/attachments/20160903/9767b31f/attachment.sig>