[opensuse-kde] rpmlint errors
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@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Tue, Jul 26, 2011 at 1:29 PM, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
Hi Todd,
Let me try to answer some of your questions.
What about 1? It seems that these packages could be arranged better.
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.
Alright, I'll ignore it when I think, and ask on this mailing list when I think there might be a good reason to change it.
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.
The only place I can recall this one being an issue is libdmtx. I will investigate this more and provide more information when I have a better idea (I won't do anything until 4.7 is published at the earliest).
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.
Then rpmlint should probably be fixed to not include these.
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.
Will do.
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.
That's what I thought.
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.
Alright. That being said, the current setup only obsolete KDE 3.5.1, which is not available in the repos, so it doesn't prevent the installation of KDE 3.5, but on the other hand it doesn't actually do anything whatsoever.
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.
I'll compile a list and post it here, then.
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.
Okay. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (2)
-
Raymond Wooninck -
todd rme