Richard Guenther wrote:
On Tue, 22 May 2007, Stanislav Brabec wrote:
Yes, but it's related. If package changes from static to shared library and the static package was referenced as libfoo, you are in problem: All BuildRequires are now broken.
Huh? If you had a static library only the BuildRequires should have been to FOO-devel. And that may actually have been the only package that existed. Now, at the point you introduce a shared library you simply introduce a lib package for it and be done.
I have had static only library "check". Now upstream moved to shared library and I had to update BuildRequires of all packages to "check-devel". See the bottom of this mail for proposed change.
Is it allowed to package shared library altogether with development files (.a, .pc, .so, .h)?
No. This is strictly forbidden.
Is it allowed to package development files to package, which does not have -devel in its name?
This should also not be done.
Agree for both. Could it be mentioned in the policy. Or is it already a part of another policy?
Shared libraries may reside in /lib{,64} or /usr/lib{,64} only if there are development files packages separately in a -devel package to link against those libraries. See (1) on how to handle different cases.
This looks too strict. There are many packages, which create shared library for more binaries inside one package. What is the benefit to link say metacity binaries with /usr/lib/metacity/libmetacity-private.so.0 instead of /usr/lib/libmetacity-private.so.0? This rule will need additional wirk to change many packages and additional work even to check that all packages conform to this rule.
It avoids polluting the global shlib namespace.
But still: It needs an additional work to even check conformance to this rule. And the result is having one directory with file and link instead of file and link in the libdir, need of rpath, and diverging from upstream.
I changed it to
" If more than one version of a -devel package can be installed at the same time (for example because includes are packaged in a versioned directory and shared libraries have a versioned name like libgtk1.so.1) the -devel packages should be suffixed with a number that allows identifying the version of the library (usually this is the same number as the shared library package suffix $NUM). So such a -devel package would be named lib$NAME$NUM-devel. "
Agree.
"Files needed to develop programs using shared libraries contained in lib$NAME$NUM.rpm are packaged in a -devel package. Those files include lib*.so, lib*.la and all headers. Optionally those files can also be placed in $NAME.rpm, in the case that it also comes with other tools or documentation. But _if_ there is a *-devel.rpm package then it contains all lib*.{so,la} and headers." or did you, above, object to "Optionally those files can also be placed in $NAME.rpm..." especially?
I propose to add: If placing of development files to $NAME.rpm can introduce future confusion, add virtual "Provides: %{name}-devel = %{version}" and refer to package in BuildRequires as $NAME-devel. It covers above mentioned problem of static -> shared library move and a situation, when strictly development package starts to provide runtime files. -- 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 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org