Dan,
So far the logic for having modules packed as separated packages was
100% driven by the dependencies (as external libs) of the module - if
the module requires dependencies of other packages, it is separately
packed. The idea was to avoid forcing people to install extra package
just because the opensips package has some modules they may not even need.
But as for any rule, I'm open to improvements, if you have a better idea :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit 2019
https://www.opensips.org/events/Summit-2019Amsterdam/
On 06/20/2019 11:28 AM, Dan Pascu wrote:
I was wondering if it wouldn't make more sense to include minimalist modules
like the new uuid in the core package instead of splitting them into their own
package.
Right now there are 42 debian packages generated by opensips. This is a bit
excessive and it gets even worse with every new module added that is also made
its own standalone package.
IMO it makes sense to split modules into their own packages if:
1. Thy have a niche use case (few people use them or they are very specialized)
2. If they are complementary to each other (like for example database modules,
where most of the time only one is used per installation)
3. If they add some heavy dependencies that are not desired for the main
package.
I'd say anything more than 12-15 sub packages is pushing it.
--
Dan
_______________________________________________
Devel mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
