On pe, 18 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
This does not work for server components and is not generalizable. For
example, you cannot have multiple versions of Samba running on the same
system. You cannot have multiple versions of FreeIPA running on the same
system either. These server components have requirements beyond package
installability.
Technically, you can, on a different port. Of course, this kind of service
is probably more or less useless on a non-default port though.
But you would not be running multiple versions of the server at once. Why
would you want to do that? You would possibly parallel-install the client
libraries, if you have software linked to different versions of it, but why
the server?
That's my point -- requiring parallel installability is not really a
MUST, especially in my area. You are driving this requirement as if nothing
else could solve your issues.
Servers are typically pretty much leaf applications and as such can be
handled as any other leaf application, by shipping a default version in the
distribution and alternate versions in a module. Of course, if the server
links to the client library (e.g., MySQL and early versions of MariaDB used
to do that, before the separate MariaDB Connector/C was introduced), then
the module must include a version of the client library packaged in a way
that does not conflict with the system version that client applications are
linked to. But this can always be done.
Exactly, and this is what we do (in RHEL). We were thinking on making a
similar setup for Samba AD in modules in Fedora, but didn't go too far
because $TIME.
We have an answer for those use cases with VMs and containers and they
aren't requiring parallel installability.
Parallel installability of leaf software is not what I am proposing. It is
only needed for libraries.
Libraries I can understand.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
