Re: Is 50+ RPM Subpackages too extreme?

[Martin Kolman <mkolman@xxxxxxxxxx>]

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 usecases

where 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 your

image 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 <lead2gold@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________

devel mailing list -- 

devel@xxxxxxxxxxxxxxxxxxxxxxx

To unsubscribe send an email to 

devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx