No dia 2 de Janeiro de 2011 20:55, Philip Brown <[email protected]> escreveu: > Deal with the reasons on their merits, please? Let's have a factual > comparison of arguments for each way.
Let's start with what shared libraries are and what they are for. Long story short, they are providing functionality to binaries. We have a standard place to keep them: /opt/csw/lib, with optional subdirectories for additional architectures, if necessary. When compiling new software, we're using the standard flags: -L/opt/csw/lib -R/opt/csw/lib which link against libraries in /opt/csw/lib and set the RPATH to look there. In principle, we could put shared libraries anywhere, but we wanted to make our lives easier and chose to have a standard place for them. There are some shared objects which are not public shared libraries; for example Kerberos ships libraries against which Kerberos binaries link, but other binaries don't. Therefore, we need to distinguish between private and public shared libraries. What should be the criteria for public shared libraries placement? If we chose to have a standard place, we should stick to it. Public shared libraries should be put under /opt/csw/lib, because only then they will be found during linking, without tweaking any environment variables and/or linker flags. Shared libraries have the status of a common resource, and once put into place, they serve many binaries and many packages. The original software that put them in place doesn't matter that much, because once any other package starts to link against them, they have to stay in place until the dependent binary goes away. The original package that provided them might even go away, but shared libraries have to stay. Taking all that into account, the packaging of shared libraries should be mainly driven by thinking about how these shared libraries are used by other packages and how well they integrate with the rest of CSW ecosystem. For example, a shared library under a custom prefix is not necessarily a good idea, because all programs that need to link against it, have to have a nonstandard RPATH, and the linking phase has to use nonstandard linker flags. For the sake of other maintainers, and us ourselves, we should place public shared libraries under /opt/csw/lib, and nowhere else. You can say that it's enough to place a symlink from /opt/csw/lib to another place that contains the binary file and programs will work - fine, but do we do that in other packages? We don't, we place the actual files directly under /opt/csw/lib. It's true that MySQL executables are under /opt/csw/mysql5, but it's an exception rather than a rule. If it was possible to keep these binaries directly under /opt/csw/bin, they would be kept there. MySQL binaries under /opt/csw/mysql/bin do not have their own shared libraries; they use a common resource, even though the common resource happens to be build from the same source tar file. Packages providing the MySQL shared libraries should be created according to the general rules of packaging shared libraries, and the rules is that you put them under /opt/csw/lib. Does it sound like a good reason? _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
