Help on bug reports for gdal (bug 1964)

[Michael Schwendt]

On Wed, 1 Sep 2004 12:18:06 +0200, Silke Reimer wrote:

> I announced gdal on fedora.us and last week I got some comments on
> my package[1]. Some of them are quite clear and will be fixed when I
> prepared my new package but I didn't understand all of them. Perhaps
> you can comment on them:
> 
> > Minor: 
> > * Permissions on files in *.src.rpm:
> > W: gdal strange-permission gdal-1.2.1.tar.gz 0600
> > W: gdal strange-permission gdal.spec 0664
> > W: gdal strange-permission gdal-install.patch 0664
> 
> What are the permission supposed to be?

Not group-writable, but 0644. But as the comment says, a minor issue and
not a blocker criterion. [A user, who would extract the src.rpm to /tmp,
should not get group-/world-writable files.]
 
> > Severe:
> > * Package does not honor $RPM_OPT_FLAGS
> 
> Can you please give me a pointer where I find more information on
> $RPM_OPT_FLAGS? I did have a look at
> http://fedora.redhat.com/participate/developers-guide/ but couldn't
> find anything.

$RPM_OPT_FLAGS are defined below /usr/lib/rpm and used by rpmbuild,
see beginning of an rpmbuild session log:

+ CFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686
+ export CFLAGS
+ CXXFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686
+ export CXXFLAGS
+ FFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686
+ export FFLAGS

A package should accept these flags. If it doesn't, the reason could be
that it has other CFLAGS hardcoded. It may be necessary to patch the
sources (Makefiles) somehow, e.g. hack it with sed.
 
> > * A lot of the explicit "Requires: proj, xerces-j, libjpeg,
> > shapelib, libungif,
> > zlib, libpng, postgresql-libs" ought to be dropped. Explicit
> > dependencies on
> > library package names ask for trouble. Most of the libraries surely
> > are
> > automatic dependencies already. Check output of "rpm --query
> > --requires
> > PACKAGENAME".
> 
> OK. But how can I get the information about the package that has to
> be installed to fulfill the various dependencies.

Let tools like up2date/yum/apt-get do that. Or if you insist on
installing packages with plain rpm, use "rpm --redhatprovides"
queries, e.g.

  $ rpm --redhatprovides /usr/lib/libgdk-1.2.so.0
  gtk+-1.2.10-28.1

and "rpm --aid -Uvh ...". The rpmdb-fedora package must be installed for
that to work.

> This is the reason
> why you must provide the names of all packages that have to be
> installed when you prepare a debian package.

This is Fedora Core, not Debian. Hardcoding library package names
is error-prone, because when the package is renamed or a library
is moved into a sub-package, the hardcoded dependency breaks and
increases the maintenance efforts. Explicit "Requires:" also make
it impossible to replace packages with alternatives.
http://www.fedora.us/wiki/HOWTOUseRequires

> A last issue: You mentioned to have used rpmlint on my package. So I
> did this as well and got lots of new warnings and errors among them
> 
> E: gdal executable-in-library-package /usr/bin/gdalwarp
> E: gdal non-versioned-file-in-library-package /usr/share/gdal/esri_extra.wkt
> E: gdal non-versioned-file-in-library-package /usr/share/man/man1/ogrtindex.1.gz
> W: gdal devel-file-in-non-devel-package /usr/lib/python2.3/site-packages/_gdalmodule.a
> 
> rpmlint is right: These package should rather be in gdal-bin,
> python-gdal etc. My question: How shall I define subpackage in the
> specfile so that the package names will not be libgdal-bin but gdal-bin
> etc. Is this possible? 

Yes. But rpmlint's suggestions are not mandatory. rpmlint in fedora.us is
customized a bit, but also catches many "false positives".  It is not
uncommon to have tools in library packages, e.g.  /usr/bin/foo-config
style programs or tools in the -devel package.  rpmlint is right about the
static library, though.

To create sub-packages, you would need additional spec file sections:

  %package SUBPACKAGENAME
  Summary:
  Buildrequires:
  [other tags]
  %description SUBPACKAGENAME
  %files SUBPACKAGENAME

> BTW: Is there a reason why rpmlint is not mentioned on
> http://www.fedora.us/wiki/PackageSubmissionQAPolicy? IMHO it helps
> to avoid lots of problems when packaging. Thus the packages will
> probably be of better quality when they  are announced on fedora.us.

http://www.fedora.us/wiki/PackagingHints