21 November 2007

Unpackaged files terminate a build

Unpackaged files terminate a build: "RPM 4.1 terminate builds when unpackaged binaries or documentation are found"

For the full story (and a very concise and helpful one it is) go to http://www.rpm.org/hintskinks/unpackaged/

For those that are only rebuilding/installing RPM's and have no interest in creating RPM's the following extract from that page may suffice.

----------- Snip ---------

There are several possible things that one can do when encountering this RPM packaging/debugging aide.

1) The proper fix, is to either have the %install section not install files into RPM_BUILD_ROOT that you do not want to package up. Alternatively, at the end of %install you can delete the files and/or dirs from RPM_BUILD_ROOT that you do not want to package up. You'll likely find however that many of these files *should* be packaged up, but the %files lists are incomplete so the files were always getting unincluded in your packages. The solution is to add the files to the %files lists properly, so the files get included in your packaging.

2) You may like the feature, but for one reason or another do not want to use it with a particular rpm package, or perhaps want to slowly fix the package to do the right thing, and in the meantime want to disable the feature just for this one package. I do this in the XFree86 packaging currently, as migrating XFree86 to package files cleanly with this feature enabled, and have it work on 7 architectures is a huge chore. To disable it in one package, add the following to the spec file:
%define _unpackaged_files_terminate_build 0
%define _missing_doc_files_terminate_build 0

3) Some users may not like it. A pity because it is a godsend. If someone does not like it at all, they can disable the feature globally by putting the following in ~/.rpmmacros:
_unpackaged_files_terminate_build 0
_missing_doc_files_terminate_build 0
----------- Snip ------------

The general gist I pickup is that a package that throws these errors is flawed, and the package creator should be alerted to this problem. However, if it installed and worked correctly using previous versions of RPM, then using fix 2 or 3 should work. Especially since trying to fix the problem (that's fix number 1) may be well beyond the ability of a "standard" user wanting to install some software package from a source rpm they had used previously.