Re: [Pkg-emacsen-addons] Bug#911553: RFS: rtags/2.20-1 [ITP]
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
Reply to: