[opensuse-packaging] rpmlint error shlib-policy-missing-suffix?
|Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what? Thanks Dave P | -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/1/24 Dave Plater
|Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what?
Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: |Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what?
Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
The lib dir contains :- libbaccfg.so.1 libbacfind.so libbac.la libbacpy.so.1 libbac.so.1 libbacsql.so libbaccfg.la libbaccfg.so.1.0.0 libbacfind.so.1 libbacpy.la libbacpy.so.1.0.0 libbac.so.1.0.0 libbacsql.so.1 libbaccfg.so libbacfind.la libbacfind.so.1.0.0 libbacpy.so libbac.so libbacsql.la libbacsql.so.1.0.0 I see that the co-maintainer has put the .la and plain .so libs in the devel package, is this right? Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/1/24 Dave Plater
On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: |Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what?
Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
The lib dir contains :- libbaccfg.so.1 libbacfind.so libbac.la libbacpy.so.1 libbac.so.1 libbacsql.so libbaccfg.la libbaccfg.so.1.0.0 libbacfind.so.1 libbacpy.la libbacpy.so.1.0.0 libbac.so.1.0.0 libbacsql.so.1 libbaccfg.so libbacfind.la libbacfind.so.1.0.0 libbacpy.so libbac.so libbacsql.la libbacsql.so.1.0.0
I see that the co-maintainer has put the .la and plain .so libs in the devel package, is this right?
Yes, .la and .so files go to the -devel package. The SLPP says so in the point that start with "Files needed to develop programs using shared libraries". But in "Best Practices" it also says: "Avoid packaging libtool config files (.la files)...". So .la files shouldn't be packaged if they aren't **really** needed. The rpmlint warning comes from: %files server ... %{_libdir}/libbac*.so.* The ".so.*" files should go to a new package (or packageS) named as SLPP says. I don't know if it's the case, but If the only binaries that will use these libraries are contained in the -server package it isn't a "real" problem. But still splitting them would do no harm. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/24/2010 12:41 PM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: |Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what?
Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
The lib dir contains :- libbaccfg.so.1 libbacfind.so libbac.la libbacpy.so.1 libbac.so.1 libbacsql.so libbaccfg.la libbaccfg.so.1.0.0 libbacfind.so.1 libbacpy.la libbacpy.so.1.0.0 libbac.so.1.0.0 libbacsql.so.1 libbaccfg.so libbacfind.la libbacfind.so.1.0.0 libbacpy.so libbac.so libbacsql.la libbacsql.so.1.0.0
I see that the co-maintainer has put the .la and plain .so libs in the devel package, is this right?
Yes, .la and .so files go to the -devel package. The SLPP says so in the point that start with "Files needed to develop programs using shared libraries". But in "Best Practices" it also says: "Avoid packaging libtool config files (.la files)...". So .la files shouldn't be packaged if they aren't **really** needed.
The rpmlint warning comes from: %files server ... %{_libdir}/libbac*.so.*
The ".so.*" files should go to a new package (or packageS) named as SLPP says. I don't know if it's the case, but If the only binaries that will use these libraries are contained in the -server package it isn't a "real" problem. But still splitting them would do no harm.
The devel package was created (I think) to remove the rpmlint complaint about the devel packages and now the complaint is about putting the libs in another package which would increase the number of rpms by about five because there are three derivatives of each lib. The libs are only for the bacula package so I can safely ignore the warning. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/1/24 Dave Plater
On 01/24/2010 12:41 PM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: |Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what?
Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
The lib dir contains :- libbaccfg.so.1 libbacfind.so libbac.la libbacpy.so.1 libbac.so.1 libbacsql.so libbaccfg.la libbaccfg.so.1.0.0 libbacfind.so.1 libbacpy.la libbacpy.so.1.0.0 libbac.so.1.0.0 libbacsql.so.1 libbaccfg.so libbacfind.la libbacfind.so.1.0.0 libbacpy.so libbac.so libbacsql.la libbacsql.so.1.0.0
I see that the co-maintainer has put the .la and plain .so libs in the devel package, is this right?
Yes, .la and .so files go to the -devel package. The SLPP says so in the point that start with "Files needed to develop programs using shared libraries". But in "Best Practices" it also says: "Avoid packaging libtool config files (.la files)...". So .la files shouldn't be packaged if they aren't **really** needed.
The rpmlint warning comes from: %files server ... %{_libdir}/libbac*.so.*
The ".so.*" files should go to a new package (or packageS) named as SLPP says. I don't know if it's the case, but If the only binaries that will use these libraries are contained in the -server package it isn't a "real" problem. But still splitting them would do no harm.
The devel package was created (I think) to remove the rpmlint complaint about the devel packages and now the complaint is about putting the libs in another package which would increase the number of rpms by about five because there are three derivatives of each lib. The libs are only for the bacula package so I can safely ignore the warning.
I did a *very quick* look at bacula. It seems they allow the use of plugins, but these don't use any data/function from the bacula libraries. And bacula devs expect plugin developers to include the needed headers from bacula in its tarballls... It doesn't makes much sense to me, but it really looks like bacula libraries aren't supposed to be used by any third party. What that means is that you can just delete the .so and .la files, there is no need for a -devel package. The current one, since has no headers, has no use anyway. Notice the "Package Contents"sections of SLPP says: "lib$NAME$NUM.rpm either contains exactly one shared library named lib$NAME.so.* or it contains multiple shared libraries. It does not contain documentation or license files." and "lib$NAME$NUM.rpm may only contain multiple shared libraries if the SO versions of all of them change at the same time always, in lockstep". Perhaps you just need a single extra RPM, not "about five". It seems "bacula" and "bacula-server" both contain all the shared libraries, duplicated. It could make sense to put the common part in a bacula-common package... or, in this case, in a libbac1 package as rpmlint asks. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/24/2010 03:08 PM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: On 01/24/2010 12:41 PM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: |Hi, the explanation for "||shlib-policy-missing-suffix ||Your package containing shared libraries does not end in a digit and should probably be split.||" seems to be missing from: http://en.opensuse.org/Packaging/RpmLint What does it mean, what libs and split into what?
Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
The lib dir contains :- libbaccfg.so.1 libbacfind.so libbac.la libbacpy.so.1 libbac.so.1 libbacsql.so libbaccfg.la libbaccfg.so.1.0.0 libbacfind.so.1 libbacpy.la libbacpy.so.1.0.0 libbac.so.1.0.0 libbacsql.so.1 libbaccfg.so libbacfind.la libbacfind.so.1.0.0 libbacpy.so libbac.so libbacsql.la libbacsql.so.1.0.0
I see that the co-maintainer has put the .la and plain .so libs in the devel package, is this right?
Yes, .la and .so files go to the -devel package. The SLPP says so in the point that start with "Files needed to develop programs using shared libraries". But in "Best Practices" it also says: "Avoid packaging libtool config files (.la files)...". So .la files shouldn't be packaged if they aren't **really** needed.
The rpmlint warning comes from: %files server ... %{_libdir}/libbac*.so.*
The ".so.*" files should go to a new package (or packageS) named as SLPP says. I don't know if it's the case, but If the only binaries that will use these libraries are contained in the -server package it isn't a "real" problem. But still splitting them would do no harm.
The devel package was created (I think) to remove the rpmlint complaint about the devel packages and now the complaint is about putting the libs in another package which would increase the number of rpms by about five because there are three derivatives of each lib. The libs are only for the bacula package so I can safely ignore the warning.
I did a *very quick* look at bacula. It seems they allow the use of plugins, but these don't use any data/function from the bacula libraries. And bacula devs expect plugin developers to include the needed headers from bacula in its tarballls... It doesn't makes much sense to me, but it really looks like bacula libraries aren't supposed to be used by any third party. What that means is that you can just delete the .so and .la files, there is no need for a -devel package. The current one, since has no headers, has no use anyway.
Notice the "Package Contents"sections of SLPP says: "lib$NAME$NUM.rpm either contains exactly one shared library named lib$NAME.so.* or it contains multiple shared libraries. It does not contain documentation or license files." and "lib$NAME$NUM.rpm may only contain multiple shared libraries if the SO versions of all of them change at the same time always, in lockstep". Perhaps you just need a single extra RPM, not "about five". It seems "bacula" and "bacula-server" both contain all the shared libraries, duplicated. It could make sense to put the common part in a bacula-common package... or, in this case, in a libbac1 package as rpmlint asks.
I really don't know which libraries go with the three binaries, bacula-sd = client, bacula-fd = server and bacula-dir which is needed for the configuration utils to communicate. What linux util can I use to find out which libs the binaries need? JFYI there is a set of libs with the same name for each db variation and they are all different. As far as the devel package is concerned it was created by the other maintainer and I need to ask him if they are actually needed. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/24/2010 03:45 PM, Dave Plater wrote:
On 01/24/2010 03:08 PM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: On 01/24/2010 12:41 PM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:
2010/1/24 Dave Plater
: > |Hi, the explanation for "||shlib-policy-missing-suffix ||Your package > containing shared libraries does not end in a digit and should > probably be split.||" seems to be missing from: > http://en.opensuse.org/Packaging/RpmLint > What does it mean, what libs and split into what? > > > > Just that shared libraries must be packaged following this: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
The lib dir contains :- libbaccfg.so.1 libbacfind.so libbac.la libbacpy.so.1 libbac.so.1 libbacsql.so libbaccfg.la libbaccfg.so.1.0.0 libbacfind.so.1 libbacpy.la libbacpy.so.1.0.0 libbac.so.1.0.0 libbacsql.so.1 libbaccfg.so libbacfind.la libbacfind.so.1.0.0 libbacpy.so libbac.so libbacsql.la libbacsql.so.1.0.0
I see that the co-maintainer has put the .la and plain .so libs in the devel package, is this right?
Yes, .la and .so files go to the -devel package. The SLPP says so in the point that start with "Files needed to develop programs using shared libraries". But in "Best Practices" it also says: "Avoid packaging libtool config files (.la files)...". So .la files shouldn't be packaged if they aren't **really** needed.
The rpmlint warning comes from: %files server ... %{_libdir}/libbac*.so.*
The ".so.*" files should go to a new package (or packageS) named as SLPP says. I don't know if it's the case, but If the only binaries that will use these libraries are contained in the -server package it isn't a "real" problem. But still splitting them would do no harm.
The devel package was created (I think) to remove the rpmlint complaint about the devel packages and now the complaint is about putting the libs in another package which would increase the number of rpms by about five because there are three derivatives of each lib. The libs are only for the bacula package so I can safely ignore the warning.
I did a *very quick* look at bacula. It seems they allow the use of plugins, but these don't use any data/function from the bacula libraries. And bacula devs expect plugin developers to include the needed headers from bacula in its tarballls... It doesn't makes much sense to me, but it really looks like bacula libraries aren't supposed to be used by any third party. What that means is that you can just delete the .so and .la files, there is no need for a -devel package. The current one, since has no headers, has no use anyway.
Notice the "Package Contents"sections of SLPP says: "lib$NAME$NUM.rpm either contains exactly one shared library named lib$NAME.so.* or it contains multiple shared libraries. It does not contain documentation or license files." and "lib$NAME$NUM.rpm may only contain multiple shared libraries if the SO versions of all of them change at the same time always, in lockstep". Perhaps you just need a single extra RPM, not "about five". It seems "bacula" and "bacula-server" both contain all the shared libraries, duplicated. It could make sense to put the common part in a bacula-common package... or, in this case, in a libbac1 package as rpmlint asks.
I really don't know which libraries go with the three binaries, bacula-sd = client, bacula-fd = server and bacula-dir which is needed for the configuration utils to communicate. What linux util can I use to find out which libs the binaries need? JFYI there is a set of libs with the same name for each db variation and they are all different. As far as the devel package is concerned it was created by the other maintainer and I need to ask him if they are actually needed. Regards Dave P
ldd shows that bacula-dir + either fd (client) or sd (server) needs all the libs anyway. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (2)
-
Cristian Morales Vega
-
Dave Plater