Hi Sourav,

On Saturday, October 27, 2012 12:25 AM, Sourav Basu wrote:

Hi,

I came up with a few more checks that I couldn't understand. Hope someone can help me out.

*Package is not relocatable.(all i could find about it from wikis is that its strongly discouraged)

The guidelines explain why this is discouraged: http://fedoraproject.org/wiki/Packaging:Guidelines#Relocatable_packages

But indeed they don't explain what a relocatable package is.

However, a quick search on your favorite search engine for the words « Linux relocatable » leads to this page:

http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_...

Which I believe makes it clearer.

*Useful -debuginfo package or justification otherwise.

To understand that you will need to understand how binaries work on Linux.

First, this only applies to packages containing binaries, i.e when the source code gets actually compiled.

When building with GCC, you can build with the optional argument `-g`. This adds all the debugging informations to the binary. THat's very useful for developers, as it helps locating the part of the program which is misbehaving. So Fedora packages are always built with that option.

But that makes a bigger binary, which can have an impact on the performance of the program at run time. The debugging informations are only used in **some** cases (when needing to debug the program), so the idea is to avoid having a negative impact on **all** users of the program.

So the debug informations are « stripped » from the binary, and put in a separate -debuginfo package. (this is done automatically by rpmbuild)

This package must contain the correct files to help developers debug the program. It must not be empty, and the spec file must not contain any directive telling rpmbuild to not build the -debuginfo subpackage...

... Or, the packager must justify why they are disabling the -debuginfo subpackage, with a comment in the spec file. Because sometimes, disabling it is the only option.

*If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.

What is unclear about that?

The source code that is being packaged must be in a Free/Open Source license acceptable for Fedora: https://fedoraproject.org/wiki/Licensing:Main

When you download a source tarball, you need to be able to tell what the license is.

Usually, the author will indicate that in the README, or in a header for each source code file.

The best practice (I think it might even be a requirement for the GPL) is to also include a file, containing the full text of the license. This file is usually called COPYING or LICENSE.

Fedora prefers this file to be included in every source package. However, because this is a legal matter, only upstream should add this file. The Fedora packager MUST NOT add the file themselves. Instead, they SHOULD ask upstream to add the file to their source tarball.

Also I wanted to ask that is it necessary that the package has to be valid on every SHOULD item?

Well, they are SHOULD, not MUST.

The meanings of the words SHOULD and MUST are even explained on the relevant wiki page: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines

All in all, it seems to me (and accept my apologies if that is not the case) that you might lack some more basic knowledge about the workings of Linux and/or how binaries are built and linked. Fortunately, every knowledge can be learnt. :)

I would strongly suggest that you try and understand a bit more about these things. Maybe try writing a simple « hello world » in C, and compile it. Try understanding some `gcc` options like `-g`, `-l` (lower-case L) or `-I` (upper-case i). Try understanding the basics of `Makefile`s maybe.

This will all help make much more sense of the packaging guidelines, and especially why they are this way.

And of course, continue asking specific questions when in doubt! :)

However, the questions you asked above are IMHO much more suited to the development mailing-list: https://lists.fedoraproject.org/mailman/listinfo/devel

Cheers,