I suggest adding eclass that would aid in packaging ELPA releases, including signed ones. Reproducible: Always I suggest adding “elpa” eclass that would streamline packaging of ELPA packages in Gentoo, GNU ELPA ones in particular. I have a a working prototype in elpa-eclass branch on Gitlab. It fills in SRC_URI and provides (configurable) verify-sig support. We also implement GNU ELPA's pgp key support and add two existing app-emacs ebuilds revisions as examples: https://gitlab.com/akater/gentoo/-/commits/elpa-eclass/ It probably needs to be improved, stylistically at least, but it works. I don't yet know how to properly support “dir” ELPA packages (as opposed to “tar” and “single”) as I found no examples of such so far.
There already is a gs-elpa.eclass in the gnu-elpa repository (supporting ELPA, MELPA, and Marmelade), available via app-portage/gs-elpa.
Sorry, for some reason I thought this bug was immediately closed. I installed app-portage/gs-elpa and familiarized myself with gnu-elpa repository. Unlike my prototype, gs-elpa.eclass does not support verify-sig or live ebuilds with git-r3. But that is only tangentially relevant. Do you suggest that I contribute to gs-elpa instead? Using it involves a lot of indirection: install keyworded app-portage/gs-elpa with lots of its irrelevant dependencies, many of them keyworded too, then add an unofficial auto-generated repository. My goal was to improve (simplify and enhance) Elisp ebuilds in the main tree, and I'm not interested in helping a Python-driven unofficial repository. Or maybe I misunderstood what you meant when you directed me to gs-elpa?
