Bug#903282: Bundling a potential 'home-end' debian package
On 2018-07-30 13:55, Nicholas D Steeves wrote: > 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. I don't have a specific intent. From the programming design perspective it makes sense to maintain them independently, but from the perspective of a distribution, it would be piling on two more debian packages for a very minor feature of a program. For a person not using either MELPA or debian, it means an extra download / un-compress operation. > 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? No, but if they want it, they already know who I am, and I'm happy to perform the assignment. > > 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] Huh? How does that math work? How do you auto-magically get those more volunteers (rhetorical question, no need to answer in writing)? > > > 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. $ apt-cache show emacs25 |grep dh-elpa I'm not getting an indication that debian is requiring / suggesting / recommending the install of that package. Should I file that as a bug against all emacsen? How? I then thought that maybe the dependency should only be upon the class of debian elpa-* packages, but performing the same check for elpa-org likewise came up with nothing (BTW, isn't org-mode now packaged by fsf itself as part of emacs, and installed by all debian emacs core packages?). > eg: A user installs elpa-libfoo=1.0 and elpa-bar-mode=1.0; tldr; (nothing personal, just not for now, for me). > Finally, no one is going to do a copyright review for the entirety of > MELPA. Now that's a real policy issue to respect, if you aren't respecting MELPA's own due diligence. > Unmaintainable mega package that is impossible to QA as a whole. Maintenance and QA of the mega-package is by upstream, as is the case for emacs itself (the mother of all mega-packages - my latest head-slap is 'M-x proc-ed' ...); why should debian be micro-managing individual features / extensions of such mega-upstream-packages on an opt-in basis? (another question for your consideration but don't need to respond here in writing). > > 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) ... that already exists currently for the entire emacs community. Any individual component would still need to be manually installed / loaded by the individual user-account, but it would be a completely local operation, not requiring a specific site-wide intervention of a sysadmin. > and will slow down package upgrades If I understand you correctly, quite the opposite. The semi-automatic site-wide upgrading of debian by a sysadmin is going to be more current, consistent, and reliable than that of each individual user-account remembering to manually check and update their local MELPA downloads. > and Emacs initialisation, Ah, I wasn't clear. My intent was not to propose that debian have emacs load all MELPA packages upon launching any
Bug#903282: Bundling a potential 'home-end' debian package
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
Bug#903282: Bundling a potential 'home-end' debian package
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
