Dear Boruch, On Mon, Jul 30, 2018 at 01:14:20AM -0400, Boruch Baum wrote: > > 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).
They can be in the same repository, if the intent is for home-end.el and keypress-multi-event.el to always have equal versions and every update to one file necessitates upgrading both packages, because a tag stores the state of the branch. Is that the intent? Magit did it this way for a while. If keypress-multi-event.el is a library that would be useful to most GNU Emacs users, then—ideally—a patch should be submitted to GNU Emacs. I noticed that you're willing to assign © to the FSF, so maybe this is the plan? It makes sense to keep them as separate files to make upstreaming a portion of your work easier rather than merging keypress-multi-event.el into home-end.el :-) As a counterpoint, Elpy (many files!) currently bundles yasnippet-snippets that are useful to Python programmers who don't use elpy, so I'm in the middle of a PR to merge them into yasnippet-snippets. After that they will be unbundled. Thanks to Sean Whitton for pointing this out, and for Jorgen Schaefer (upstream maintainer of Elpy) for ACKing the unbundling. > Also, does debian have any strong feelings on where such a repository > should be hosted (eg. microsoft). From what I've heard from others, Github is fine...I think it's up to you. Proportionally few projects migrated from Github to Gitlab following the Microsoft acquisition, and personally I think that Github will probably remain the Linkedin of code. > 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. One reason emacs-goodies-el is being broken up is to distribute the burden of maintenance of x packages between y volunteers, where previously it was 1 mega-package that no one had time to maintain. [3] > 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. Dh-elpa protects against this. eg: A user installs elpa-libfoo=1.0 and elpa-bar-mode=1.0; list-packages will display the status "external" for both packages, and list-packages will not upgrade these packages from MELPA to MELPA versions. A user wants to install, from MELPA, zebra-1.0, which depends on libfoo-1.5. After selecting libfoo from the menu, the *Help* buffer will show zebra-1.0 as "Status: Incompatible in /path/to/lib-foo-1.0". Installing an elpafied Debian package protects the user from upstream changes to elisp libraries (eg: not rolling). If a user wants wildebeest-5.0, from MELPA, and has not installed elpa-wildebeest, and wildebeest-5.0 depends on <=libfoo-1.0 then a user can install this package from MELPA. > 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); Installing packages from MELPA via Packages.el is not curation. Maintaining a separate list of packages or a puppet configuration might count as a weak form of curation (creating a list assigns value). > 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. Already implemented on a per-elpa package basis, see above. > 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. That's not curation, that's replication with a blacklist. The following process is, at best, weak curation: 1) build a whitelist 2) maintain this whitelist by adding and removing elements. Finally, no one is going to do a copyright review for the entirety of MELPA, so the entirety of MELPA will never be part of Debian...nor should it be. [3] Unmaintainable mega package that is impossible to QA as a whole. We dropped a handful of packages from emacs-goodies-el that were below the 20th percentile of downloads counts, even though they were on MELPA. If a user misses one we'll bring it back of course :-) > 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. "Every package" is a massive exploitable attack surface (and source of bugs) and will slow down package upgrades and Emacs initialisation, not to mention impossible to QA. A MELPA mirror or a web cache would also save bandwidth. > 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. This should do the trick apt install elpa-.* Package-foo might still exist as a transitional package to elpa-package-foo. Please mention a few packages (from MELPA) that don't have a corresponding elpa-package. Those are outliers that need to be elpafied. > 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). https://github.com/melpa/melpa/issues/2342 To the best of my knowledge, this is not going to happen in Debian either. Yes, curating a blacklist is a weak form of curation; however, curating a blacklist against an unbounded package set is more work than curating a (bounded) whitelist...and emacs-goodies-el was the package that held curated emacswiki content. AFAIK it also curated lisp files from mailing lists and personal web pages before that. Transitioning away from years of history and uncountable hours of hard work maintaining this monolith towards a set of packages is 86% complete. Curation is a more involved process than maintaining lists. P.P.S. You mentioned you're at debconf? To meet the team, #debian-emacs on irc.oftc.net Cheers, Nicholas
signature.asc
Description: PGP signature
