Hi, > 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 is already on salsa at https://salsa.debian.org/danilov-guest/rtags if you add my account danilov-guest to the emacs-team, I can clone the repo and continue it there. > > 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. Combined into one package it will pull through the dependencies simultaneously company vs auto-complete and helm vs ivy. And then if someone does not want to have for example ivy, will have to disable it manually (due to autoloads etc.) With a separate elpa-ivy-rtags package you just don't install it and nothing will pull elpa-ivy. Therefore I prefer to have then separated. -- Denis Danilov
