[Bug 489233] Review Request: rmol - C++ Revenue Management Optimisation Library (RMOL)

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=489233





--- Comment #9 from Michael Schwendt <bugs.michael at gmx.net>  2009-03-24 11:02:11 EDT ---
* Be careful:

> -%configure --enable-static --with-docdir=%{_docdir}/%{name}-%{version}
> +#%configure --with-docdir=%{_docdir}/%{name}-%{version}
> +%configure

Some macros cannot be disabled/commented like this. Here the %configure macro
is still executed twice. Safe is to replace '%' with '#'. [In %changelog, use
double '%%' when referring to macro names.]


* The conflict between %doc and the installed html documentation tree still
exists. "make install" copies the html tree to
$RPM_BUILD_ROOT/usr/share/doc/rmol-0.19.0/ where it is deleted/overwritten with
your %doc statements. To get the html tree into your -doc subpackage, you add
it from the local build directory. What may seem to work here, breaks with
other packages. You would lose some installed doc files silently. It's not a
blocker, but one way to shoot yourself into the feet.

A common work-around [even when --with-docdir= cannot be redefined to point it
to a temporary directory] is to actually use the installed documentation files
rather the the local ones from the build dir. E.g.

  %define mydocs __tmp_docdir

  %install
  ...
  make install ...
  ...
  rm -rf %{mydocs} && mkdir %{mydocs}
  mv $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version}/*  %{mydocs}


  %files doc
  ...
  %doc mydocs/*
  %doc other files here

That way you can modify/fix the %{mydocs} tree after "make install" instead of
modifying the extracted source tarball prior to "make install". Very convenient
if you ever want to use --short-circuit builds during trouble-shooting.

[With that method, one pitfall remains, and that is related to applications
which expect the documentation files in the installed %docdir. One must be
careful not to move the files to a different location that doesn't match with
the paths compiled into the application/program executables.]


* The following change creates an "unowned directory":

> -%{_includedir}/%{name}
> +%{_includedir}/%{name}/RMOL_Service.hpp
> +%{_includedir}/%{name}/RMOL_Types.hpp

%dir %{_includedir}/%{name}   is necessary to fix that.
https://fedoraproject.org/wiki/Packaging/UnownedDirectories


> /usr/share/aclocal/rmol.m4

I think it is acceptable not to "Requires: automake" just for this directory --
as long as the guidelines don't force packagers to do it:

| MUST: A package must own all directories that it creates. If it does
| not create a directory that it uses, then it should require a package
| which does create that directory

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership


* spectool rmol.spec 
Source0: http://download.sourceforge.net/rmol/rmol-0.19.0.tar.gz
 -> ERROR 404: Not Found.
http://downloads.sourceforge.net/rmol/rmol-0.19.0.tar.gz
 -> would work

Tarball in the src.rpm doesn't match your upstream release!


* Scratch-build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1256538

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.