Mailinglist Archive: opensuse-kde (297 mails)

[Raymond Wooninck <tittiatcoke@xxxxxxxxx>]

Hi Todd,

Let me try to answer some of your questions.

> 2. "shlib-policy-missing-suffix: Your package containing shared
> libraries does not end in a digit and should probably be split." This

There have been quite some discussions around this particular topic
and the answer has always been that packages belonging to KDE or to
GNOME are not always following the guidelines given by rpmlint. The
desktop packages have been packaged in a logical way and this is not
always inline with rpmlint. As you said already a good example is
bluedevil. There is already a package libbluedevil that provides the
core libraries. What would be the reason to start splitting out the
package bluedevil itself and to start providing a new rpm which is
called bluedevil-libs. This would create much more confusion, then
just this simple rpmlint error.

My comment would be here to ignore this warning when it comes to
bigger desktop packages.


> 3. "shlib-policy-missing-lib: Your package starts with 'lib' as part

As indicated above, just ignore this warning. Renaming packages would
create a big confusion and would eventually end up with more issues
than just this trivial warning.

> 4. "devel-file-in-non-devel-package (Badness: 50)"  These appear when

It completely depends on what files are indicated here. For KDE we
have also *.so files in the /usr/lib64/kde4 directory and these are
NOT development files. These are library modules required by the KDE
desktop. And I am sure that there are plenty more of these type of
files.

> 5. "package-with-huge-docs  x%: More than half the size of your

The create of a separate rpm on itself is not bad especially when the
doc-package would be optional and therefore could save diskspace for
the user.

> 6. "explicit-lib-dependency: You must let rpm find the library

Most of the time these requires are there to explicitly request for a
specific version of that package. It is sometimes not enough to have
rpm resolve the dependency itself as that an older version of the
package might also satisfy the dependencies, but the newer version is
required.

> 7. Obsoletion of KDE 3.5.1.  A lot of packages obsolete KDE 3.5.1.  Is

I guess that currently we can remove a lot of obsolete and provides. I
don't think that we have any user that is still running with packages
with the prefix kde4. Also with KDE 3.x still existing, I believe that
we should make it possible to have both installed at the same.

> 8. "non-executable-script: This text file contains a shebang or is

This should be validated case by case. Not in all-cases the text file
should be made executable as that this could cause security issues,
etc.

> 9. Commented commands in .spec file: Do you think that commands that
> have been commented out can be removed?

> A special case: akonadi obsoletes itself, since it used to follow the
I would remove the obsoletes/provides here as that I don't believe
that anybody is still running an older version.

Regards

Raymond
--
To unsubscribe, e-mail: opensuse-kde+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kde+help@xxxxxxxxxxxx