Hi Ralf, On Thu, Jan 24, 2019 at 07:52:18AM +0100, Ralf Treinen wrote: > Hi Nicholas, > > thanks for working on this package. You're welcome :-) > On Tue, Jan 22, 2019 at 03:45:40PM -0700, Nicholas D Steeves wrote: > > > Done. Here's the MR: > > > > https://salsa.debian.org/ocaml-team/tuareg-mode/merge_requests/1 > > > > Please note that autopkgtests for Tuareg require one of: > > > > 1. ocaml-mode being elpafied too. > > 2. a manual workaround to pull in ocaml-mode to the autopkgtestbed. > > I will look to your proposed changes soon. Though I do not see > why you mixed this up with unrelated cosmetic modifications. Renaming > tuareg-mode, however, is out of question. I included the whitespace cleanup as a courtesy, and for the sake of completeness. Is it unwanted? Unless I made a mistake somewhere there should be one operation per commit so it will be easy to drop any unwanted commits. As for bin:tuareg-mode vs bin:elpa-tuareg-mode, the former requires extra work (kind of like a "Provides: virtual-package", but for Package.el rather than dpkg). Here is a brief case for bin:elpa-tuareg 1. Compatibility with GNU ELPA/MELPA/Package.el without extra work. eg: https://melpa.org/#/tuareg, and not https://melpa.org/#/tuareg-mode 2. The mode is named "tuareg.el", "tuareg.el" has "(provide 'tuareg)" rather than "(provide 'tuareg-mode)". 3. Upstream README.md refers to the software as "Tuareg" rather than "tuareg-mode". I edited the descriptions for consistency with MELPA and upstream documentation. Do you prefer consistency with historical/existing Debian package names rather than consistency with what Emacs uses for its own dependency resolution and with MELPA? That's fine with me, but please share your rationale. Also affects bin:ocaml-mode vs bin:elpa-caml I'd be happy to do a v2 MR asap, after learning what the contentious issues/commits are. :-) Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature