On Wed, 2019-11-27 at 07:44 +0100, Igor Gnatenko wrote: > No, 50 is perfectly fine. As others mentioned, we have much bigger amount of > them in texlive. Yeah, I also don't really see a problem in making packages more granular. There are many usecaseswhere you want that, such as installation images or minimal cloud images and containers. If packages are not granular, you need to resort to ugly hacks that are hard to maintain if you want to make yourimage smaller. With granular packages you can install only what you really need, no hacks required!
> If those are like plugins which may or may not require other packages, I > would split them. And probably put Recommends > in the main package for the most used ones. > > On Wed, Nov 27, 2019, 02:58 Chris <lead2g...@gmail.com> wrote: > > Hi guys, > > > > I just wanted to poll you for some advice. My notification tool I maintain > > supports more than 50+ services now, but > > the only package isolation I do within 2 RPMs. One for the actual CLI (for > > admin's who want to use it) and the > > other is for the backend library (for Devs). I only ask because each > > supported service is very modular. > > > > I kind of like the way nagios-plugins breaks apart it's check_scripts into > > many sub-packages, but 50+ subpackages > > seems a bit extreme... or is it? It certainly seems like a bit of a > > nightmare to maintain; it would be one very > > large .spec file. > > > > You can see the directory structure here on GitHub: > > https://github.com/caronc/apprise > > > > Effectively every single file in "apprise/plugins/Notify*.py" is it's own > > plugin-able module. You can add/remove > > content into here and the tool adapts. Thus the sub-packages would only > > include 1 file per RPM. > > > > Is it advisable to go this route? I presume there is no easy way to > > transition without breaking users existing > > setup? I don't know what the d/l stats are; so there may not be a large > > enough audience to even need to worry about > > this? > > > > What are your thoughts and/or advice? > > _______________________________________________ > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > _______________________________________________devel mailing list -- > devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
