Thank you all for replying with so much information! I just had a few comments:
+ I'm officially afraid of the texlive spec file.
+ Sérgio: In regards to why sub-packages:
* Purely for modularity and isolation. Users who just use Apprise for... say Discord and Email, don't need the other 49 packages. But someone hosting a notification web service might want all of them except the ones that utilize local libraries (one uses the DBus interface as an example). Each package has absolutely no external dependences except maybe 2.
+ Samuel: Thank you for your points.
* I don't honestly think my package really has much of a following. So I see maybe frustrating a handful of people at worst case by changing everything up. But you still raise some good points. Maybe I could do what 'nagios-plugins' does and has a general package that does nothing but 'Recommends' (or Requires) many others (hauling them all in). This was brought up by Igor; i like this idea.
+ Tom: Thank you for the lua example!
* While this is somewhat cryptic to me at first glance (not knowing it); I imagine once it works, it doesn't have to be touched again. Of the 50 some odd services (to-be-sub-packages), about 2 of them actually have external dependencies. I presume there is some black magic taking place in the %build section that is allowing these templates to work?
+ Richard: Thank you very much for sharing those references, I had a look into each specfile and first of... whoa... they're very big.... But one thing I noticed is nbdkit is slightly inconsistent with some of the other package (or vs versa?):
* sub-packages in nbdkit are formatted as: 'ndbkit-{name}-{type}' (where {type} would be plugin) while other packages (such as libvirt) does it's sub-packages as 'libvirtd-{type}-{plugin}'. Is there a preference or a standard I should use?
+ I'm officially afraid of the texlive spec file.
+ Sérgio: In regards to why sub-packages:
* Purely for modularity and isolation. Users who just use Apprise for... say Discord and Email, don't need the other 49 packages. But someone hosting a notification web service might want all of them except the ones that utilize local libraries (one uses the DBus interface as an example). Each package has absolutely no external dependences except maybe 2.
+ Samuel: Thank you for your points.
* I don't honestly think my package really has much of a following. So I see maybe frustrating a handful of people at worst case by changing everything up. But you still raise some good points. Maybe I could do what 'nagios-plugins' does and has a general package that does nothing but 'Recommends' (or Requires) many others (hauling them all in). This was brought up by Igor; i like this idea.
+ Tom: Thank you for the lua example!
* While this is somewhat cryptic to me at first glance (not knowing it); I imagine once it works, it doesn't have to be touched again. Of the 50 some odd services (to-be-sub-packages), about 2 of them actually have external dependencies. I presume there is some black magic taking place in the %build section that is allowing these templates to work?
* Here is what my current working-spec-file looks like (without sub-packages): https://github.com/caronc/apprise/blob/master/packaging/redhat/python-apprise.spec
* Since I really want to maintain backwards compatibility with EPEL7, I imagine I'm going to have double the entries to accommodate Python 2.7 references too... :(
+ Richard: Thank you very much for sharing those references, I had a look into each specfile and first of... whoa... they're very big.... But one thing I noticed is nbdkit is slightly inconsistent with some of the other package (or vs versa?):
* sub-packages in nbdkit are formatted as: 'ndbkit-{name}-{type}' (where {type} would be plugin) while other packages (such as libvirt) does it's sub-packages as 'libvirtd-{type}-{plugin}'. Is there a preference or a standard I should use?
* Also, this goes slightly against Tom's suggestion (using an lua in-line script). While everything is in plain English using your examples; well, it's just 'a-lot' of content. I saw some discussion going back and forth which is better; but I guess it's preference at the end.
Chris
On Wed, Nov 27, 2019 at 12:38 PM Chris Adams <linux@xxxxxxxxxxx> wrote:
Once upon a time, Matej Grabovsky <mgrabovs@xxxxxxxxxx> said:
> Can you please explain what you mean? What are the alternatives if
> there really are over 5000 packages in CTAN?
Why does all of CTAN need to go into one source RPM?
--
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
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
