ref: https://github.com/melpa/melpa/pull/5594
The method I used to re-write 'home-end' for MELPA was to first write a small generic el that handles an arbitrary number of responses for an arbitrary number of repeated key-presses for an arbitrary key (I'm calling it 'keypress-multi-event'), and then have my version of 'home-end' use that as its back-end. For the purpose of debian packaging, should those two files (each very small, BTW) be packaged separately? Does debian want each small file to be in a separate repository (eg., on github). Also, does debian have any strong feelings on where such a repository should be hosted (eg. microsoft). In the bigger picture, I question the 'efficiency' of administering emacs packages this way. Debian is setting itself up for a tremendous amount of work involving potentially hundreds of MELPA packages. Going through the use-cases and scenarios in my head, it doesn't make sense to me that on the one hand debian is not restricting individual user accounts from using MELPA (eg. by removing / patching-out functions from package.el ), but on the other hand is curating a MELPA subset that individual user accounts would potentially be duplicating in their local user-space, with much potential for version mis-matching. Two alternatives to consider would be to: 1] Package nothing that is available on MELPA; let MELPA handle it, and let individual users curate packages for themselves (debian already allows them to self-curate using MELPA, anyway); 2] Package the entirety of MELPA as a single debian package, and remove the package.el functionality of external downloading (hear me out, please...) 2.1] A user-account could always 'opt-in' to over-ride that policy by copying 'package.el' from an external source. 2.2] This would allow debian to curate all MELPA packages using a blacklist method of patching the *single* debian package (ie. to remove a MELPA component deemed insecure / unsafe), much simpler than managing n < zillion small debian packages. 2.3] On large enterprise debian installations (eg. universities), this would save a lot of redundant bandwidth and storage, since all of MELPA would already be local. 2.4] Currently, if a debian administrator does want to locally offer all MELPA packages that are currently packaged by debian, is there even a way to simply do that? I see no meta-package that brings in all of them, and the naming convention is inconsistent. 2.5] Debian could similarly address the policy conflict between MELPA and emacswiki users such as Drew, by curating a similar single curated package for emacswiki content (maybe in that case a lot of red-ink blacklisting to happen for all the very old cruft that might be there, but that would be a one-time operation, and could be simplified by using a modification date cut-off). -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
