Mailinglist Archive: opensuse-packaging (161 mails)

< Previous Next >
Re: [opensuse-packaging] rpmlint error shlib-policy-missing-suffix?
  • From: Dave Plater <dplater@xxxxxxxxxxxxxxxx>
  • Date: Sun, 24 Jan 2010 16:44:36 +0200
  • Message-id: <4B5C5CD4.7070005@xxxxxxxxxxxxxxxx>
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 <dplater@xxxxxxxxxxxxxxxx>:

On 01/24/2010 12:41 PM, Cristian Morales Vega wrote:

2010/1/24 Dave Plater <dplater@xxxxxxxxxxxxxxxx>:

On 01/24/2010 11:25 AM, Cristian Morales Vega wrote:

2010/1/24 Dave Plater <dplater@xxxxxxxxxxxxxxxx>:

|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:
What does it mean, what libs and split into what?

Just that shared libraries must be packaged following this:

The lib dir contains :-

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

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$* 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.
Dave P

ldd shows that bacula-dir + either fd (client) or sd (server) needs all
the libs anyway.
Dave P
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >