On Oct 12, 2006, Enrico Scholz <enrico.scholz@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Axel.Thimm@xxxxxxxxxx (Axel Thimm) writes: >> Revisting the root of evil. What exactly is wrong with not removing >> all *.la files? > - .la files must be shipped in main package, not in -devel Only if users of the library rely on libltdl and explicitly refer to the .la files. > - they add untracked dependencies to the rpm packages: when B was built > against A which has libA.la, B will stop to work when A does not ship > libA.la anymore (e.g. because it uses now cmake). rpm might be improved to track such dependencies automatically. Or the package ought to list its dependencies explicitly. That's just a packaging bug. Quite inconvenient, I agree. But if A changes its interface by removing the .la file (and that is a change of interface for libtool users), then someone must deal with the consequences. It's not really much different from renaming a library or a header file or moving them to a different directory. Users (as in dependent packages, not people who run the software) are affected by such changes, and that's unfortunate. But it's not libtool that is to blame, it's the removal of the .la file, that was in place before and went missing, and the absence of an rpm dependency reflecting the actual dependency given by the .la files. If you remove a header file from a library, users of that header file will lose just the same. > - .la files are not required In the absence of static libraries, on GNU/Linux systems, they aren't, indeed. In their presence, given a few additional constraints that are relatively easy to comply with, it makes things a bit smaller and faster, so the move is probably a reasonable step, in spite kf the breakage that the removal of interface files (I'm talking about the .la files) is going to cause. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging