Packagers Tips and Hints

[TerryN]

Some notes about dependency management

Many people who are new to packaging think that dependency management is only about the Provides: and Requires: tags in the spec file. These are only part of the story because rpm does automatic dependency generation as part of the rpmbuild process for programs which are compiled (C, C++ etc.).  Therefore in general it is not necessary to add any Provides: or Requires: tags for these types of package.  In fact, adding unnecessary Requires: tags can cause problems if a library package name changes or on 64 bit (where library packages can be named differently anyway).  The general rule is to only add Requires: tags for packages consisting of script languages (python, perl, bash etc.) or where the required package is desirable (to add functionality) rather than necessary (to install the package).

This automatic dependency generation is handled by 2 scripts find-provides and find-requires which you will see run towards the end of the build.

find-provides
This script examines all the files in the %files list and if any shared libraries are found the soname of the lib is added to the list of capabilities/facilities provided by the rpm.  This means that if another package depends on that shared lib your package can be selected by apt/synaptic to satisfy that dependency.  Be very careful when packaging apps where the SOURCES contain pre-built libraries as they will be added and you could find your package being selected as a dependency of a seemingly totally unrelated application (Calibre springs to mind).  Worse still, this can lead to instability if those libraries are used with another application (because they were not built on PCLinuxOS).  To avoid this you can add:

Code: [Select]

Autoprov: Noto the summary section of the spec file (that is where the Provides/BuildRequires/Requires/Obsoletes tags go) for these types of package (and only these types of package!).  Documentation for these tags is here.

find-requires
This script examines all the files in the %files list and effectively runs an ldd on any executable to see what shared-libraries are needed by the executable.  The sonames for these libraries are added to the list of capabilities required by the rpm and will need to be resolved when the rpm is installed.  Once again pre-built binaries in the SOURCE can cause issues as they may reference sonames which cannot be resolved by existing packages in the repo.  An example would be because the SOURCE contains binaries for multiple architectures (see example here)

Devel dependencies (added Jul 5)
There is a further twist with shared objects which are to be used as system shared libraries (there are other uses for .so files). The build will produce 3 "copies" of the lib (actually only 1 is a real file the others are links but that doesn't matter for the purposes here) :

/usr/lib/libxyz.so.1.2.3
/usr/lib/libxyz.so.1
/usr/lib/libxyz.so

The first 2 (the versioned files) are required at runtime and should be in the main package.  The 3rd one (libxyz.so) is only required by the linker when building apps against the shared lib and should therefore be in the -devel package (along with header files).

RPM is clever enough to know this and generates "devel" provides/requires for that file.  Therefore if you put the unversioned .so in the main package the automatic dependency management will generate a "devel" provides:

Code: [Select]

[terry@localhost ~]$ rpm -q --provides kde-workspace-core | grep devel
devel(libkwinglesutils) 
devel(libkwinglutils) 
devel(liboxygenstyleconfig) 
devel(libpowerdevilconfigcommonprivate) 
devel(libpowerdevilui)
and therefore devel dependencies:

Code: [Select]

[terry@localhost ~]$ rpm -qR kde-workspace-core | grep devel
devel(libdl) 
devel(libEGL) 
devel(libgcc_s) 
devel(libGL) 
devel(libGLESv2) 
devel(libICE) 
devel(libkdecore) 
devel(libkdeui) 
devel(libkephal) 
devel(libkwineffects) 
devel(libm) 
devel(libpowerdevilcore) 
devel(libpowerdevilui) 
devel(libQtCore) 
devel(libQtDBus) 
devel(libQtGui) 
devel(libQtSvg) 
devel(libSM) 
devel(libstdc++) 
devel(libX11) 
devel(libXau) 
devel(libXdmcp) 
devel(libXext) 
devel(libXft) 
devel(libXpm
and these devel dependencies will have their own dependencies etc. etc.  This could result in a large amount of unnecessary -devel packages and other "build" packages being installed on systems which are not used for software building.  This can consume a lot of space and make things like remastering more difficult.

If you are sure that nothing will ever want to link/build against such a library you could avoid creating a -devel subpackage by either deleting the .so at the end of the %install section

Code: [Select]

rm -f %buildroot/%{_libdir}/libxyz.so
or using a %exclude for the file in the %files list.

Code: [Select]

%files
...
%exclude %{_libdir}/libxyz.so

but if there is any doubt it is safer to provide a -devel package.

To summarize, great care must be taken with dependency management when dealing with system shared libraries.  It is complicated, tedious and certainly not glamorous but it IS necessary to avoid the repo descending into bloat and chaos.
 
Terry.

[Neal ManBear]

Good one, Terry. Now tell them where to add Autoprov: No when it is needed.     

[TerryN]

Good one, Terry. Now tell them where to add Autoprov: No when it is needed.     

Edited accordingly 

[Neal ManBear]

Good one, Terry. Now tell them where to add Autoprov: No when it is needed.     

Edited accordingly 

     
Good deal, Terry. Thanks.      

[gseaman]

Only <glib.h>

Code: [Select]

error "Only <glib.h> can be included directly.  
Search for an patch file, or create your own.

As sample

diff -uNr src.orig/mw_debug.c src/mw_debug.c
--- src.orig/mw_debug.c   2005-12-03 04:46:10.000000000 +0100
+++ src/mw_debug.c   2012-03-26 22:28:57.000000000 +0200
@@ -19,7 +19,7 @@
 */
 
 
-#include <glib/gstring.h>
+#include <glib.h>
 
 #include "mw_debug.h"

Go inside the source code package, copy'n'rename source file as name.orig.
Edit name file and, start a terminal and type

Code: [Select]

diff -uNr name.orig name > my-name.patch

-l

Sometimes when using patch, the patch will apply perfectly, but will create .orig copies of things that are patched. This may only happen if patch finds a match and applies the code, but is off-set a few lines from where it is expected. Then, if you create use diff -uNr to create a new patch it is larger than the original. For example, if a patch works in kernel-3.2.16 is applied to 3.2.18 but the line numbers don't match, the patch may still work, but gives warnings and makes the *.orig copies. If you want a version of the patch without the warnings, you can re-diff, but you need to remove all of the extra files.

Code: [Select]

rm -f *.orig */*.orig */*/*.orig */*/*/*.origThis should do it all at once.

Galen

[Archie]

I usually inspect the patches before including them on updates. It's extra work but can ensure that the patches are proper. Often contents of the patches have already been applied to the updates or line numbers do not match or the diff do not exist, etc. These causes errors during the first part of the builds.

We should make it a habit to at least "skim through" the patches before running rpmbuild -ba. 

[ghostbunny]

No Tip but a request

could someone post the rpm commands for testing a package against the rpm database which packages  need the specific version.

it was something like

rpm --whatdepends

someone told me the command but its lost somewhere in my brain

And is it also possible to test against the full repo not only the installed programs?

Thanks in advance

regards
ghostbunny

[Just17]

apt-cache whatdepends  <name>       ?

[JohnW_57]

An example is here:  http://www.pclinuxos.com/forum/index.php/topic,109678.msg937447.html#msg937447

If I'm correct. 

JohnW

[TerryN]

apt-cache whatdepends  <rpm>       ?

No, not <rpm>.  The part after whatdepends has to be a "capability" name (packagers should know what that means).
See also here http://www.pclinuxos.com/forum/index.php/topic,110221.msg940996.html#msg940996

Unfortunately, some packagers are adding unnecessary "Requires:" tags to SPEC files  specifying package names rather than capabilities (instead of letting the automatic dependency mechanism do it's job) which can lead to problems when apt/Synaptic has to resolve dependencies (especially on 64 bit systems where the package name often does not match the capability name).

Terry.

[ghostbunny]

Thank you friends

This helps a lot.

[pinoc]

To all packagers:

Can you please try to setup your SRPMS to build on 32 as well as 64, else we will never get the 64bit repo completed. More importantly having a common SRPM for the two architectures will save server space, avoid duplicated work and potential error sources.

If your spec builds on both platforms then please add the following informational header at the beginning of your spec-files:

# 32/64bit spec-file
#

so other packagers will know that this is a 32/64bit compatible spec-file.

If your spec-file will only build on 32bit or 64 bit then the header should read either

# 32bit spec-file
#

or

#64bit spec-file
#

and the resulting SRPM should be named <package>_32bit....src.rpm  or <package>_32bit....src.rpm to clearly label it for the respective platform. Ideally we should aim to get any package build on 32bit and 64bit from the same SRPM.

thanks!
-p.