Cristian Morales Vega wrote:

Well, just that. Sometimes I find a -devel package requires another one, why? I do that when the pkg-config file has a "Requires: XXX" and rpmlint complains the same isn't in the RPM spec file, but normally I also don't see why the .pc file has such an entry.

It is not a rpmlint, but an old style build check script. There are two checks: .pc check: Checks that all files listed in .pc are in Requires of the rpm, so you can easily add Requires: foo-devel and everything needed is included. Starting with rpm 4.6, this check will be obsolete, as rpm itself will automatically require and provide these packages. .la check: This is an another story. When .la file is present, you have to have all .la files listed there, otherwise linking fails. That is why it is better to remove .la files if you are not packaging static library nor use libltdl.

One case that makes sense is if the library is statically compiled and depends on another library, but that's no the common case. So, to know when I have to fix a .pc file (that should use Requires.private instead of Requires if the problem are static librariries) and when I must follow what it says... in which case a -devel package should depend on another one?

The check above now ignores Requires.private, so only missing Requires dependencies are reported. One may consider it is a bug.

With shared libraries I can't think of any valid case...

True if you don't have .la file. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2009/5/28 Stanislav Brabec <sbrabec@suse.cz>:

Cristian Morales Vega wrote:

...

Well, just that. Sometimes I find a -devel package requires another one, why? I do that when the pkg-config file has a "Requires: XXX" and rpmlint complains the same isn't in the RPM spec file, but normally I also don't see why the .pc file has such an entry.

It is not a rpmlint, but an old style build check script.

There are two checks:

.pc check: Checks that all files listed in .pc are in Requires of the rpm, so you can easily add Requires: foo-devel and everything needed is included. Starting with rpm 4.6, this check will be obsolete, as rpm itself will automatically require and provide these packages.

...there is any decision about when the upgrade to rpm 4.6 will be done? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Cristian Morales Vega escribió:

That really happens?

yes, an almost universal example is the requirement of glibc-devel in some way or another. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi,

.la check: This is an another story. When .la file is present, you have to have all .la files listed there, otherwise linking fails. That is why it is better to remove .la files if you are not packaging static library nor use libltdl.

This, by the way, can't be emphasized enough. As a rule of thumb, don't, in any case, package .la files. As this is a rule of thumb you will see some cases where it's difficult to follow it, as it's meant to describe the ideal world, which of course sometimes conflicts with the real world. But you should go to great lengths to make it happen, including bitching to other package maintainers, those might be the reason why "your" .la can't go away. I say that as a past time developer of libtool, but .la files are not useful in the linux eco-system, so don't package them, they only create problems. Amongst the problems they create are (despite their total uselessness for shared libraries in ELF systems): 1) hardcoded dependency libraries (no matter if necessary or not) 2) hardcoded paths (link-time or run-time) for search paths to libraries, again no matter if necessary or not, those often have to be fixed up during package build time In a way that's basically it. But these problems lead to further deficiencies: too long search paths lead to longer load times of libraries (hence executables), because non-existing libraries have to be "searched". Useless dependencies for shared libraries lead to rebuilds that are not necessary, and generally to a skewed view on the dependency situation between packages. And obviously useless library dependencies have an influence also on package dependencies (creating equally artificial and hence useless ones). And as a side-effect they even lead to longer build times because libtool investigates the information in .la files very thoroughly (to use an euphemism). So, try to get rid of .la files in your packages at great costs. There are some reasons to retain them (static libs come to mind; not much else, not even plugins), but all of these reasons are special cases (we try to get rid of static libs too), so in general they don't apply. Get rid of them. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michael Matz escribió:

But you should go to great lengths to make it happen, including bitching to other package maintainers, those might be the reason why "your" .la can't go away.

Been there, done that ..painful experience. ;-)

Amongst the problems they create are (despite their total uselessness for shared libraries in ELF systems): 1) hardcoded dependency libraries (no matter if necessary or not)

getting compiler to call ld with --as-needed by default while linking "solves" this, but Im afraid that may open pandora's box and show some issues not-quite-easy to fix ...

2) hardcoded paths (link-time or run-time) for search paths to libraries, again no matter if necessary or not, those often have to be fixed up during package build time

unneded hardcoded paths at runtime can be detected and fixed by using brp-check-rpath that is used in fedora, which is (or was) quite strict last time I checked... In short, do not package *.la files _unless_ you receive a bug report that the package breaks at runtime, if dependent packages fail to build due to the lack of "la" files, you have to fix those, NOT restore "la" files. good luck :-P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michael Matz wrote:

I say that as a past time developer of libtool, but .la files are not useful in the linux eco-system, so don't package them, they only create problems.

Would it be possible to patch libtool to not create .la files in elf-linux and patch libltdl to don't depend on them? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org