Re: [Pkg-emacsen-addons] Bug#911553: RFS: rtags/2.20-1 [ITP]

[David Bremner <david@tethera.net>]

Denis Danilov <danilovdenis@yandex.ru> 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.