On Sun, Jun 16, 2019 at 2:53 AM Remi Collet <Fedora@xxxxxxxxxxxxxxxxx> wrote: > > Le 14/06/2019 à 20:03, Josh Boyer a écrit : > > On Fri, Jun 14, 2019 at 3:50 AM Remi Collet <Fedora@xxxxxxxxxxxxxxxxx> wrote: > >> > >> > >>> IMHO, having library in modules is an error, this can only raise issues > >> > >> Some examples, taken from RHEL-8 > >> > >> libJudy is part of the mariadb module ... (without -devel) > >> libssh2 is part of the virt module... (without -devel) > >> libzip is part of the php module... > >> etc > >> > >> How are we going to manage this in EPEL ? > > > > Can you elaborate further? > > How are you going to build package requiring libssh2 in EPEL ? > > Dependency on "virt" seems terribly strange > and we don't have the "devel" package, and are not allowed per > Guidelines to replace things which are part of RHEL. > > So probably we have to add libssh2 in EPEL, but what will happen if > soname change ? making installation if "virt" module impossible ? > > As "libssh2" is only used by "virt", and is not part of the provided > contract of the module, we can imagine > > - virt version x with libssh2 version 1 > - virt version y (major update = new stream) with libssh2 version 2 > - virt version y (minor update, same stream) with libssh2 version 3 > - etc > > > Next problem, I need libssh2 and libjudy (and some others) in the PHP > module, so ? > > - add a module dependency on mariadb and virt ? > > => this can't work and don't make sense > > - add the judy and libssh2 and other lib in the php module ? > > => at some point, we are going to generate conflicts between modules Why can't libssh2 be packaged into a module of its own in EPEL? Yes, this looks odd at first, but it doesn't expressly replace the RHEL version, and it allows you to have module dependencies that do make sense. Granted, that may mean modules could conflict but in this specific case I'm not immediately seeing that. If the soname changes in the libssh2 module, the installation files would also change and the virt module could continue using its own copy, right? > IMHO, such libraries have to be in the base distribution. Ah, well in many cases, yes. There are cases where a library is considered an internal implementation detail and not for general usage outside of the core functionality it was included for. Modules actually make this possible in a way, with the pitfalls you're highlighting. The usecases also differ greatly between one OS and another, so what makes sense in e.g. RHEL might not make sense in Fedora or even EPEL. josh > Another funny thing, I have some PHP extensions which use nodejs, how to > mange this in a modular world ? > > - make PHP module depends on NODEJS module ? > > - create another module only for these extensions ? > > > > For memory, PHP is not available as module in Fedora, because of such > issues (and PHP stack is hundreds of packages, with tons of library > bindings). > > But I really want to see more PHP stuff in EPEL, as for previous > version, and this have to be managed as module. > > > > > Remi > _______________________________________________ > 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
