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 emacs instance, only that debian offers a debian-ized MELPA copy, with blacklist curation. > not to mention impossible to QA. Upstream MELPA does that. > A MELPA mirror or a web cache would also save bandwidth. That is close to what this proposal would be doing. > > 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. Bad news: Quasi-randomly I checked several and had a 100% hit-rate! I started with the MELPA package wanderlust, which exists as two debian (seemingly non-transitional) packages, named: wl and wl-beta. Also, check out debian packages git-el, mu-cite, apel, flim, w3m-el, w3m-el-snapshot, puppet-el, notmuch-emacs, semi, tuareg-mode. At that point I stopped. > 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 You only need to black-list known bad actors that for some reason MELPA hasn't already black-listed. > P.P.S. You mentioned you're at debconf? Nope. > To meet the team, #debian-emacs on irc.oftc.net I could be available to help out some, but it might require someone to do some hand-holding me through the parts of the initial process (I did start and eventually abort a DM effort a few years ago). Best wishes for an enjoyable and productive trip. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Attachment:
signature.asc
Description: PGP signature