Denis Danilov <[email protected]> writes: > Hi, > > I have prepared packages for RTags C/C++ client/server indexer with > integration > for Emacs. I'm also planning to maintain it. At the moment I'm looking for > sponsor for the initial version at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911553
I don't have time in the next weeks to take on a new package, but maybe someone else on the emacsen-team is interested. Based on popularity it looks like it makes sense to have rtags in debian. I guess whether or not someone from the team sponsors the upload, it makes sense to maintain the package in the emacs-team group on salsa. Feel free to apply on salsa, I can add you. > > It builds those binary packages: > > elpa-ac-rtags - auto-complete back-end for RTags > elpa-company-rtags - company back-end for RTags > elpa-flycheck-rtags - flycheck integration for RTags > elpa-helm-rtags - helm interface for RTags > elpa-ivy-rtags - ivy back-end for RTags > elpa-rtags - emacs front-end for RTags > rtags - C/C++ client/server indexer with integration for Emacs > Normally I'm in favour of each upstream elpa package being a debian binary package, but I wonder if these needs (initially) to generate so many binary packages. elpa-rtags makes sense as a binary package, since at least one other package in melpa (malinka) depends on it. The others might be groupable into one binary package. I'm not sure if that would introduce significate maintenance overhead.
