Maciej Bliziński <[email protected]> writes: > 2011/2/3 Peter FELECAN <[email protected]>: >> Maciej Bliziński <[email protected]> writes: >> >>> 2011/2/3 Peter FELECAN <[email protected]>: >>>> I globally agree with the exception of the handling of private shared >>>> libraries: it should be optional to put these in a specific directory >>> >>> If you put a private shared library in /opt/csw/lib, wouldn't it >>> effectively make it a public one? >>> >>> Once a library is in /opt/csw/lib, you can add a -l flag to the linker >>> and link against it in the same way you link against public libraries. >>> A private library in /opt/csw/lib sounds like an oxymoron to me. >>> >>> However, there's nothing that prevents you from putting any shared >>> library of your choice into /opt/csw/lib, as long as it's packaged >>> according to the standard - meaning, it's in a separate package. >> >> I see 2 reasons for which a private library can be let in /opt/csw/lib: >> >> 1. nothing precludes to use it if the API is public; if the provider >> considers it private he had put it in a private directory and not >> supply an API > > If a library has a public API, then by definition the library is > public, I guess we both agree on that. Regarding the second part, I > would not necessarily rely on the locations of libraries as installed > by the upstream 'make install' target. I've seen projects that > install private libraries into /opt/csw/lib, and vice versa, public > libraries installed into /opt/csw/lib/foo. We can instead analyze the > upstream project's code to determine which libraries are shared and > which are public. Talking to upstream developers is also an option. > >> 2. making mandatory this kind of policy for private library >> unnecessarily complexify packaging vs Debian which doesn't have >> this kind of policy. > > It does add some complexity, I agree. But it does it for a good > reason: we want to avoid other projects accidentally linking to a > library which was thought to be private, because once this happens, > you need to take the following steps to recover: > > 1. Move the once-thought-to-be-private library from CSWfoo to a > separate package (e.g. CSWlibfoo1) > 2. Make CSWfoo depend on CSWlibfoo1 (for backward compatibility) > 3. Release CSWlibfoo1, re-release CSWfoo > 4. File a bug with CSWbar (the package which accidentally linked to > libfoo.so.1) > 5. Wait for new CSWbar to be released > 6. Remove the dependency on CSWlibfoo1 from CSWfoo > 7. Re-release CSWfoo
Have you, or anyone else encountered this case? In the affirmative please provide the example. > This kind of procedure is annoying, and I'm sure everyone would like > to avoid it, if possible. > > The mistake in the other direction (putting a public library in a > subdirectory), has less impact. To recover: > > 1. Move the library from CSWfoo to CSWlibfoo1 > 2. Make CSWfoo depend on CSWlibfoo1 (only if necessary, e.g. binaries > from CSWfoo need libfoo.so.1) > 3. Release CSWlibfoo1, re-release CSWfoo > > In the long run, this policy would be a time saver, for both > maintainers: the maintainer of CSWfoo (+CSWlibfoo1), and the > maintainer of CSWbar. > > Regarding Debian, if you read the "10.2 Libraries" section[1] of the > Debian policy, you'll see the following paragraph: > > "Shared object files (often .so files) that are not public libraries, > that is, they are not meant to be linked to by third party executables > (binaries of other packages), should be installed in subdirectories of > the /usr/lib directory. Such files are exempt from the rules that > govern ordinary shared libraries, except that they must not be > installed executable and should be stripped." I would like to emphasize the term *should* which is weaker than *must*. Again, if it's a should I agree. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
