Deprecate all emacswiki packages. #2342
Comments
|
Amen. |
|
Will you provide somewhere the complete list of the future deprecated packages ? |
|
Could deprecated packages be pulled from emacsmirror instead? I've talked to Drew Adams, and he wants to keep |
For that see #2128. I believe that while pretty much everyone around here actually involved in the mirroring and packaging of elisp thinks that the wiki no longer is a good place to distribute libraries, dropping support for it is seen more as a long time goal. Just doing it now is also an option, but I don't think the hope that this would cause the remaining libraries to be migrated to some vcs repository sooner, is really justified.
We've all been there. |
Refs: - melpa#2342 - melpa#3004 - melpa#3005
Refs: - melpa#2342 - melpa#3004 - melpa#3005
Refs: - melpa#2342 - melpa#3004 - melpa#3005
|
Apropos of the last commit referenced above, it looks like the deprecation is already done - is this issue just waiting for the last existing emacswiki recipe to actually be deleted? |
|
I've assigned this to myself as a way to keep track of it. This does not necessarily mean I will do something. |
|
This has come up on reddit again. That doesn't really change anything, but somehow it pushed me closer to advocating a clear cut. Ultimately this is up to @purcell and @milkypostman. Also I think that even if you decide to drop support for the Emacswiki, we shouldn't rush anything. (But we shouldn't let it sit for another two years either.) I'm going to produce some data on which non-wiki packages would be affected by this. Might take me a while until I get to that though, because I want to address some related issues in |
|
I think I posted before I want to remove all emacswiki packages because of this exact threat. When I do need a package from emacswiki I manually download it, I don't use melpa because I am concerned about this. I'm happy to have them removed. It seems that now is indeed the time. The percentage of emacswiki packages is low. If we remove them and people complain, I'm sure we can work it out. I.e., have someone move the package to github or other dvcs. |
|
I'm not sure that I even have any wiki-sourced packages installed, because the very idea repulses me. ;) But as a member of the community, I would appreciate them being removed for the good of all of us. I definitely think we should be proactive rather than waiting for something bad to happen. Let's just bite the bullet, and anyone who really needs wiki-sourced packages can 1) keep using what they have installed, or 2) install them manually. I really don't want MELPA to be the subject of an LWN security article someday... |
|
Here's a first table listing wiki packages that non-wiki packages depend on. It does not include any indirect dependers and it is based on automatically extracted dependency information, not the |
|
ok, this reminds me, we should leave all the 'Drew Adams' packages. he has
a deal with the emacswiki folks that his package pages are locked. but we
should verify. this doesn't fall under our motivation for doing this though.
possibly we should mirror those packages. tarsius would have to say though.
…On Wed, Apr 5, 2017 at 10:53 AM, Jonas Bernoulli ***@***.***> wrote:
Here's a first table listing wiki packages that non-wiki packages depend
on. It does not include any indirect dependencies and it is based on
automatically extracted dependency information, not the Package-Requires
header.
| Dependee (27) | Author | Depender | Fetcher | Author |
|------------------+------------------------+-------------------------------+---------+-------------------------|
| dirtree | Ye Wenbin | prosjekt | github | Austin Bingham |
| ert-expectations | rubikitch | caskxy | github | Hiroaki Otsu |
| ert-expectations | rubikitch | coverage | github | Kieran Trezona-le Comte |
| ert-expectations | rubikitch | creds | github | Antoine R. Dumont |
| ert-expectations | rubikitch | req-package | github | Edward Knyshov |
| faces+ | Drew Adams | floobits | github | Geoff Greer |
| filesets+ | Drew Adams | helm-filesets | github | Graham Clark |
| findr | David Bakhash | jump | github | Eric Schulte |
| fit-frame | Drew Adams | anything-project | github | |
| font-lock+ | Drew Adams | all-the-icons | github | Dominic Charlesworth |
| frame-fns | Drew Adams | floobits | github | Geoff Greer |
| hexrgb | Drew Adams | jabber | git | |
| hexrgb | Drew Adams | on-screen | github | Michael Heerdegen |
| hexrgb | Drew Adams | paper-theme | github | Göktuğ Kayaalp |
| hide-lines | | syslog-mode | github | Harley Gorrell |
| highlight | Drew Adams | cider-eval-sexp-fu | github | Sylvain Benner |
| highlight | Drew Adams | eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | evil-extra-operator | github | Dewdrops |
| highlight | Drew Adams | evil-search-highlight-persist | github | Juanjo Alvarez |
| highlight | Drew Adams | nrepl-eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | php-boris-minor-mode | github | steckerhalter |
| highlight | Drew Adams | sonic-pi | github | Joseph Wilk |
| http-post-simple | Tom Schutzer-Weissmann | org-readme | github | Matthew L. Fidler |
| http-post-simple | Tom Schutzer-Weissmann | tumble | github | Federico Builes |
| key-chord | | buffer-flip | github | Russell Black |
| key-chord | | use-package-chords | github | justin talbott |
| lacarte | Drew Adams | helm | github | Thierry Volpiatto |
| levenshtein | Aaron S. Hawley | cmake-ide | github | Atila Neves |
| levenshtein | Aaron S. Hawley | ten-hundred-mode | github | |
| look-mode | | look-dired | github | Joe Bloggs |
| menu-bar+ | Drew Adams | floobits | github | Geoff Greer |
| multi-term | Andy Stewart | elscreen-multi-term | github | wamei |
| multi-term | Andy Stewart | helm-mt | github | Didier Deshommes |
| multi-term | Andy Stewart | navorski | github | |
| shell-command | TSUCHIYA Masatoshi | anything | git | Tamas Patrovics |
| shell-history | rubikitch | anything | git | Tamas Patrovics |
| showtip | Ye Wenbin | sdcv | github | Andy Stewart |
| sr-speedbar | Sebastian Rose | ppd-sr-speedbar | github | Robert Dallas Gray |
| sr-speedbar | Sebastian Rose | projectile-speedbar | github | Anshul Verma |
| strings | Drew Adams | ergoemacs-mode | github | David Capello |
| thingatpt+ | Drew Adams | el-spice | github | Vedang Manerikar |
| transpose-frame | S. Irie | nu-mode | github | |
| w32-browser | Emacs Wiki, Drew Adams | nsis-mode | github | Matthew L. Fidler |
| yaoddmuse | | company | github | Nikolaj Schumacher |
| yaoddmuse | | org-readme | github | Matthew L. Fidler |
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACUsgTfmKn-SqJFZ4jrgqI1G_z5Do6qks5rs7jfgaJpZM4DN8bO>
.
|
I would strongly prefer that, especially if the mirrors were manually updated. I realize that's a chore, but I feel like leaving anything pulling from any kind of wiki is just a bad idea on principle, even if they say they have locked the pages in some way. What if the wiki were compromised someday? I guess the same could be said for any server being pulled from, even GitHub, but I still feel that wikis are generally not well engineered compared to other software and are just more risky. (I realize I'm just a noisy back seat driver here, so I will watch silently if you're tired of my chiming in.) |
|
I have added 15 of these packages to the Emacsorphanage, updated the Emacsmirror to mirror from there, and updated Melpa to import from there too. For more information about the Emacsmirror and the Emacsorphanage see https://emacsmirror.org. For information about packages in the orphanage see https://emacsmirror.net/stats/emacsorphanage.html (but note that I have not updated that yet since adding these packages). Most of these package did not see any changes in several years. A few were modified about a year ago by someone other than the author/maintainer. If some edits one of these packages on the Emacswiki going forward, then Melpa and the Emacsmirror won't pick up those changes - but that's kind of the point. If someone (including the person who previously maintained it (to some extend) on the Emacswiki) would like to maintain one of these packages, then they should contact me. These repositories contain the full history though in most cases with bad commit messages. Someone(tm) should review these packages for security risks they may already contain. |
|
Thank you for doing that, Jonas! |
|
Did the same for three more packages. Here is an updated table: |
|
And here is a table of all packages from the wiki, sorted by author. |
|
@snogglethorpe EmacsWiki is fine as a place for random snippets that people paste into their init-files. However, it is completely unacceptable as an upstream source for a package manager. I believe that you are concerned about the loss of the EmacsWiki environment as a place to put snippets, which is not something that would happen if we stopped people putting packages on EmacsWiki. |
|
@kensanata you probably overlooked this above because you were primarily invited to this discussion as the maintainer of the Emacswiki, but two of your own packages are still being imported from the wiki.
Assuming these should remain available, could you please move them to separate repositories on github? Thanks! |
|
Sure! Sadly, I won't get to it until the end of October since I'm away from my laptop. :)
|
|
October seems to have come and gone :) |
|
Thanks @kensanata - updated in e6e7569. |
|
I've updated code for a package currently hosted on Emacs-wiki, and I can't see the changes resulting in a new package for the latest MELPA builds. Is this related to Emacswiki now being deprecated? Does that apply to existing packages using that recipie too? Or could there be other reasons too? (For reference, this is the package I'm talking about). |
|
Yes. Also see melpa/package-build#9. |
|
Thanks for the quick reply. That’s very informative. Has anyone had any thoughts on what a good migration path from Emacswiki should look like, on a wider scale? Am I now forced to “git” this code and become “official” maintainer for yet another abandoned package? Or is someone planning to create a wider Github-organization where a bigger collective of co-maintainers from the Emacs-community can help out, without forcing individual users to take/claim ownership? Is this being discussed anywhere? If so I’d love some pointers and links :) |
Click on the |
|
Never mind. I see you have made some great efforts, and I see batch-mode being superseded by bat-mode supplies by Emacs core. I guess all my needs are covered, all my issues resolved and I have no further questions. Thanks for taking time to respond anyhow! |
|
i have inadvertently deleted all emacswiki packages. so we may as well delete the recipes??? |
|
@milkypostman did you also delete all the other packages :-D Currently MELPA is listing 757 packages only and there are a lot of unavailable packages when installing Spacemacs. |
|
Just saw the tweet
;-) |
Since #5008 is specifically about that, I am taking the discussion there (starting at #5008 (comment)). |
|
The recipes for wiki packages are no more. |
|
Ahhhh I just realized zoom-frm was dropped from Melpa as a result of this. If I file a PR to fetch from emacmirror for zoom-frm, will this be accepted? |
|
No. The reason the Emacswiki packages were dropped from Melpa is that anyone can edit any package on the Emacswiki, which is a security "risk" (aka no security at all). Getting these packages indirectly through the Emacsmirror doesn't change anything about that. (Also see the forth message above and follow the link). |
We should avoid all emacswiki packages in MELPA.
At this point we should also avoid adding further wiki packages.
The text was updated successfully, but these errors were encountered: