Mailinglist Archive: opensuse-kde (297 mails)
| < Previous | Next > |
[opensuse-kde] rpmlint errors
- From: todd rme <toddrme2178@xxxxxxxxx>
- Date: Tue, 26 Jul 2011 12:34:16 +0200
- Message-id: <CADb7s=utFV8qEY_uDW70Rod1aMXSZADhY+Yjai97hkJgayj5zg@mail.gmail.com>
I have been going through and fixing rpmlint errors in the KDE
packages. There are a few classes of common error, however, I have
been hesitant to fix, and want some feedback on, usually because they
require changes to which packages are actually available:
1. "no-binary: The package should be of the noarch architecture
because it doesn't contain any binaries." These are usually for the
base packages of particular groups, like "kdeutils" or "kdetoys".
However, in practice these pretty much only include documentation. I
would personally be inclined to eliminate the base packages and
instead have noarch documentation packages in these cases. Phonon is
an exception, it actually has real files, but I could probably make a
phonon-base package. Currently it is unclear from the naming what the
base packages do, if anything, so besides eliminating warning and
reducing the amount of space used it would also be clearer.
2. "shlib-policy-missing-suffix: Your package containing shared
libraries does not end in a digit and should probably be split." This
appears when shared libraries appear in a non-library package. This
would involve splitting off a new library package for the shared
libraries. This is simple in some cases, but in others is a bit more
difficult, such as bluedevil where there already is a libbluedevil.
In such cases I could call it bluedevil-libs, libbluedevil-extra,
libbluedevilgui, or something like that depending on the context.
3. "shlib-policy-missing-lib: Your package starts with 'lib' as part
of it's name, but does not provide any
libraries. It must not be called a lib-package then. Give it a more
sensible name." This is the opposite of the previous, but requires
fully renaming the package.
4. "devel-file-in-non-devel-package (Badness: 50)" These appear when
a .so (NOT .so.x or .so.x.x) file appears in a non-devel package.
This is usually a trivial fix, but I haven't fixed this since I don't
know if it is correct or not (especially since in some cases the error
appears in packages that already have a -devel sub-package). In some
cases I would need a new devel rpm, would it be alright to split
those?
5. "package-with-huge-docs x%: More than half the size of your
package is documentation. Consider splitting it into a -doc
subpackage." This should be self-evident, it just requires splitting
a doc package, but once again it requires splitting off a new rpm.
6. "explicit-lib-dependency: You must let rpm find the library
dependencies by itself. Do not put unneeded
explicit Requires: tags." I don't know whether these are in here on
purpose to fix dependencies that are not automatically detected, or if
they are errors. The most common seems to be libkeduvocdocument4.
7. Obsoletion of KDE 3.5.1. A lot of packages obsolete KDE 3.5.1. Is
this correct? It seems to be a bit of an odd number to pick, is there
a reason for it? What was the last openSUSE version to ship with KDE
3.5.1? In practice I don't think this obsoletion will accomplish
anything, it won't obsolete any version of KDE 3 people are still
using. I am thinking we probably should not be obsoleting or
providing KDE 3 packages at all, those are handled by the KDE3 repos.
8. "non-executable-script: This text file contains a shebang or is
located in a path dedicated for executables, but lacks the executable
bits and cannot thus be executed. If the file is meant to be an
executable script, add the executable bits, otherwise remove the
shebang or move the file elsewhere." Should I make these executable?
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
KDE numbering scheme (4.x) but now follows an internal one (1.x). 4.x
obsoletely 1.x. RPM has a way to handle this, it is called an
"epoch". This has precedence over the version number, and defaults to
zero. I could bump the epoch to fix this problem, and perhaps in
other similar cases. Otherwise there doesn't appear to be a clean way
to fix this.
Some things outside of my control:
RPMLINT has some bugs that should be fixed in more recent versions,
including one that prevents building some python packages. Would it
be possible to have a link to the factory version? It would probably
not be published, only used for building.
Should we be publishing update-desktop-files? It seems to be
something that is only used for building.
Finally, I think it would be worthwhile thinking about what groups
particular sorts of packages are in. They are currently completely
inconsistent for relatively similar packages. It might be good for
someone to go through an put a wiki page that lists the group for each
RPM, and then we can decide how to reorganize them up so they are more
consistent and more logical.
-Todd
--
To unsubscribe, e-mail: opensuse-kde+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kde+help@xxxxxxxxxxxx
packages. There are a few classes of common error, however, I have
been hesitant to fix, and want some feedback on, usually because they
require changes to which packages are actually available:
1. "no-binary: The package should be of the noarch architecture
because it doesn't contain any binaries." These are usually for the
base packages of particular groups, like "kdeutils" or "kdetoys".
However, in practice these pretty much only include documentation. I
would personally be inclined to eliminate the base packages and
instead have noarch documentation packages in these cases. Phonon is
an exception, it actually has real files, but I could probably make a
phonon-base package. Currently it is unclear from the naming what the
base packages do, if anything, so besides eliminating warning and
reducing the amount of space used it would also be clearer.
2. "shlib-policy-missing-suffix: Your package containing shared
libraries does not end in a digit and should probably be split." This
appears when shared libraries appear in a non-library package. This
would involve splitting off a new library package for the shared
libraries. This is simple in some cases, but in others is a bit more
difficult, such as bluedevil where there already is a libbluedevil.
In such cases I could call it bluedevil-libs, libbluedevil-extra,
libbluedevilgui, or something like that depending on the context.
3. "shlib-policy-missing-lib: Your package starts with 'lib' as part
of it's name, but does not provide any
libraries. It must not be called a lib-package then. Give it a more
sensible name." This is the opposite of the previous, but requires
fully renaming the package.
4. "devel-file-in-non-devel-package (Badness: 50)" These appear when
a .so (NOT .so.x or .so.x.x) file appears in a non-devel package.
This is usually a trivial fix, but I haven't fixed this since I don't
know if it is correct or not (especially since in some cases the error
appears in packages that already have a -devel sub-package). In some
cases I would need a new devel rpm, would it be alright to split
those?
5. "package-with-huge-docs x%: More than half the size of your
package is documentation. Consider splitting it into a -doc
subpackage." This should be self-evident, it just requires splitting
a doc package, but once again it requires splitting off a new rpm.
6. "explicit-lib-dependency: You must let rpm find the library
dependencies by itself. Do not put unneeded
explicit Requires: tags." I don't know whether these are in here on
purpose to fix dependencies that are not automatically detected, or if
they are errors. The most common seems to be libkeduvocdocument4.
7. Obsoletion of KDE 3.5.1. A lot of packages obsolete KDE 3.5.1. Is
this correct? It seems to be a bit of an odd number to pick, is there
a reason for it? What was the last openSUSE version to ship with KDE
3.5.1? In practice I don't think this obsoletion will accomplish
anything, it won't obsolete any version of KDE 3 people are still
using. I am thinking we probably should not be obsoleting or
providing KDE 3 packages at all, those are handled by the KDE3 repos.
8. "non-executable-script: This text file contains a shebang or is
located in a path dedicated for executables, but lacks the executable
bits and cannot thus be executed. If the file is meant to be an
executable script, add the executable bits, otherwise remove the
shebang or move the file elsewhere." Should I make these executable?
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
KDE numbering scheme (4.x) but now follows an internal one (1.x). 4.x
obsoletely 1.x. RPM has a way to handle this, it is called an
"epoch". This has precedence over the version number, and defaults to
zero. I could bump the epoch to fix this problem, and perhaps in
other similar cases. Otherwise there doesn't appear to be a clean way
to fix this.
Some things outside of my control:
RPMLINT has some bugs that should be fixed in more recent versions,
including one that prevents building some python packages. Would it
be possible to have a link to the factory version? It would probably
not be published, only used for building.
Should we be publishing update-desktop-files? It seems to be
something that is only used for building.
Finally, I think it would be worthwhile thinking about what groups
particular sorts of packages are in. They are currently completely
inconsistent for relatively similar packages. It might be good for
someone to go through an put a wiki page that lists the group for each
RPM, and then we can decide how to reorganize them up so they are more
consistent and more logical.
-Todd
--
To unsubscribe, e-mail: opensuse-kde+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kde+help@xxxxxxxxxxxx
| < Previous | Next > |