Re: [opensuse-factory] Meeting Minutes Dist Meeting 2007-05-10
Richard Guenther wrote:
On Tue, 22 May 2007, Andreas Jaeger wrote:
Stanislav Brabec <sbrabec@suse.cz> writes:
Andreas Jaeger wrote:
* Shared library policy see: http://en.opensuse.org/Shared_Library_Packaging_Policy
0) Static only packages 1) Packages with some devel files in the main package.
If package is static only or package provides devel files (e. g. .pc file) without splitting -devel package, it must provide -devel package, either as a virtual symbol or as a package (by skipping of file list of the main package).
Packages linking against the library or referring devel files from the package (e. g. .pc files), must refer to foo-devel, not foo.
It allows painless move to shared library and painless splitting in future.
Example: package foo with static-only stuff: Provides: %{name}-devel = %{version}-%{release}
Real life example: Package check moved from static to shared library after 10.2. Several other packages were splitted. Both raised need to adopt many other packages.
So, what is your objection here?
I don't get this either. Note the shared libaray naming and packaging policy is about shared libraries, not static ones or naming a -devel (or not -devel) package.
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. The second mentioned thing can be re-formulated as a missing item in the policy: Is it allowed to package shared library altogether with development files (.a, .pc, .so, .h)? Is it allowed to package development files to package, which does not have -devel in its name? I think that it should not be permitted, even if it causes bigger number of packages. Otherwise it introduces missing devel dependencies (see below).
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.
2) Naming of devel package.
So my proposal:
Shared library package should be named libgsf1_114, but devel package should be named libgsf1.
This is exactly what the policy suggests. Where do you read otherwise? Maybe the wording can be improved.
No, it suggests libgsf1_114-devel: If more than one version of a -devel package can be installed at the same time ... the -devel packages should be suffixed with the same number as the shared library package. Proposed change: If more than one version of a -devel package can be installed at the same time ... the -devel packages should be suffixed with the same number as the shared library package. If package provides a pkg-config file or another development configuration script or shared library uses epoch number, the -devel packages should be suffixed with the number of it.
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 the same number as the shared library package, lib$NAME$NUM-devel.
I see this is a quote from the policy. The wording needs to improve here as $NUM does not suggest a suffix different from $SONAME is allowed.
But it's already part of the policy, last article "Package Naming". Andreas Jaeger wrote:
There is not yet any tool for automatic collecting of devel
dependencies, but I am thinking about a tool collecting packages from .pc files and #include.
Preferred way to do it: Requires: %{name} = %{version}
And how can we get rid of these later again? We currently have a lot of packages with too many dependencies ;-(
We need an automatic tool for it. Missing devel dependencies introduces additional BuildRequires in other packages which are even worse to get rid. It is definitely not complicated for .pc files, but more complicated for .la files and .h 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
On Tue, 22 May 2007, Stanislav Brabec wrote:
Richard Guenther wrote:
On Tue, 22 May 2007, Andreas Jaeger wrote:
Stanislav Brabec <sbrabec@suse.cz> writes:
Andreas Jaeger wrote:
* Shared library policy see: http://en.opensuse.org/Shared_Library_Packaging_Policy
0) Static only packages 1) Packages with some devel files in the main package.
If package is static only or package provides devel files (e. g. .pc file) without splitting -devel package, it must provide -devel package, either as a virtual symbol or as a package (by skipping of file list of the main package).
Packages linking against the library or referring devel files from the package (e. g. .pc files), must refer to foo-devel, not foo.
It allows painless move to shared library and painless splitting in future.
Example: package foo with static-only stuff: Provides: %{name}-devel = %{version}-%{release}
Real life example: Package check moved from static to shared library after 10.2. Several other packages were splitted. Both raised need to adopt many other packages.
So, what is your objection here?
I don't get this either. Note the shared libaray naming and packaging policy is about shared libraries, not static ones or naming a -devel (or not -devel) package.
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.
The second mentioned thing can be re-formulated as a missing item in the policy:
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.
I think that it should not be permitted, even if it causes bigger number of packages. Otherwise it introduces missing devel dependencies (see below).
Sure, but again this is only on the edge of the shlib policy (maybe we shouldn't have added all the words about the non-shlib parts).
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.
2) Naming of devel package.
So my proposal:
Shared library package should be named libgsf1_114, but devel package should be named libgsf1.
This is exactly what the policy suggests. Where do you read otherwise? Maybe the wording can be improved.
No, it suggests libgsf1_114-devel:
If more than one version of a -devel package can be installed at the same time ... the -devel packages should be suffixed with the same number as the shared library package.
Proposed change:
If more than one version of a -devel package can be installed at the same time ... the -devel packages should be suffixed with the same number as the shared library package. If package provides a pkg-config file or another development configuration script or shared library uses epoch number, the -devel packages should be suffixed with the number of it.
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. "
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 the same number as the shared library package, lib$NAME$NUM-devel.
I see this is a quote from the policy. The wording needs to improve here as $NUM does not suggest a suffix different from $SONAME is allowed.
But it's already part of the policy, last article "Package Naming".
Hm, yes. I'll see to move this sections to a footnote instead and retain "Packages with suffix -devel should in general omit $NUM as -devel packages for different library versions usually conflict due to common header file names." in Package Naming and change the wording in Package Contents to "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? Thanks, Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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
participants (2)
-
Richard Guenther -
Stanislav Brabec