Alexandre Oliva <aoliva@xxxxxxxxxx> writes: >>>> - .la files must be shipped in main package, not in -devel > ... > Aah, I think I see what you mean. > > libfoo.la is a loadable module. > > libbar.la is a library in a separate package that libfoo.la was linked > with. > > Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not > available. > > Is this what you mean? yes > /me wonders if his reasoning breaks if both libfoo and libbar are in > the same package. no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is added to the repository a year later by a different maintainer. Therefore, 'libbar.la' must be handled like 'libbar.so.0' and must be in the main package but not in devel. >> Because a library can be linked against arbitrary .la modules, a >> library must either remove .la files completely or ship them in the >> main package. > > I don't think this follows. It does hold that they probably ought to be in > the same package, or arranged such that the package containing libfoo.la > requires that containing libbar.la. Exactly. Because (usually) main packages (e.g. this with 'libfoo.la') must not depend on -devel packages, the required 'libbar.la' must not be in -devel but in a main package. Automatic dependencies (by interpreting 'dependency_libs') will prevent silent breakage but do not change this rule. Checking only the current state of the repository does not help. There exists always the chance that 'libX.la' is used later by some loadable module (which is shipped in a main package). Enrico
Attachment:
pgpfwE1qKtJ1S.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
