Bug 187266

Someone hopped in while I was writing this, but I'll include these comments anyway.

I may not be qualified to review this, but here are some quick comments:

You comment that it will only compile with -O1 but then substitute in -O0.

Consider adding a comment describing why you substitute out @TXT_FILES@ from
Makefile.in.

Is it acceptable to have the executable under /usr/lib/gprolog-blah/bin and put
a symlink into /usr/bin?  The only examples I can find of this in Core are QT
and RPM.

Do you still need to delete the doc files (Changelog, COPYING, etc.) after you
have removed @TXT_FILES@ from Makefile.in?  Changing the "rm -f" to "rm" shows
that the files don't need to be deleted.

rpmlint complains about /bin/sh dependencies in the doc files.  I think that you
could safely delete BINPROLOG, CIAO, SICSTUS, SWI, WAMCC, XSB and YAP from the
ExamplesPl directory; they aren't even intended to be used by gprolog.

Comment #1 already mentions the things that should be fixed.
Have you created the patches yourself, or do they come from elsewhere?
If they do, it may be useful to document this.

The patches are coming from the gentoo project.

1. Its seem to work without subsitutation of @TSTFILES@, so I have remove this line.

2. I think yes.

3. see 1.

4. I think this is not a problem, becouse this are samples from gprolog-examples.

I have uploaded a new release at:

SPEC: http://www.herr-schmitt.de/pub/gprolog/gprolog.spec
SRPM: http://www.herr-schmitt.de/pub/gprolog/gprolog-1.2.19-2.src.rpm

(In reply to comment #1)
> could safely delete BINPROLOG, CIAO, SICSTUS, SWI, WAMCC, XSB and YAP from the
> ExamplesPl directory; they aren't even intended to be used by gprolog.
These should really be deleted!

Corrected version:

SPEC: http://www.herr-schmitt.de/pub/gprolog/gprolog.spec
SRPM: http://www.herr-schmitt.de/pub/gprolog/gprolog-1.2.19-3.src.rpm

Output of rpmlint gprolog:
W: gprolog devel-file-in-non-devel-package
/usr/lib/gprolog-1.2.19/lib/libengine_fd.a
W: gprolog devel-file-in-non-devel-package /usr/lib/gprolog-1.2.19/lib/libbips_pl.a
W: gprolog devel-file-in-non-devel-package /usr/lib/gprolog-1.2.19/lib/libbips_fd.a
W: gprolog devel-file-in-non-devel-package /usr/lib/gprolog-1.2.19/include/gprolog.h
W: gprolog devel-file-in-non-devel-package
/usr/lib/gprolog-1.2.19/lib/libengine_pl.a
W: gprolog devel-file-in-non-devel-package /usr/lib/gprolog-1.2.19/lib/liblinedit.a
W: gprolog devel-file-in-non-devel-package /usr/lib/gprolog-1.2.19/include/fd_to_c.h

Would it make sense to split off the prolog to c compiler into
an extra package. This would contains these object files and
the compiler programs gplc, ma2asm, etc...

rpmlint of gprolog src rpm:
E: gprolog configure-without-libdir-spec

Will adding --libdir=%{_libdir} to the configure command line break the build?
Note, that on x86_64, %{_libdir} will be /usr/lib64.

I have create a new release of the RPMs. 

SPEC: http://www.herr-schmitt.de/pub/gprolog/gprolog.spec
SRPM: http://www.herr-schmitt.de/pub/gprolog/gprolog-1.2.19-4.src.rpm

Becouse I don't have a 64-bit engine, it will be nice, if anyone can doublecheck
the use of the --libdir option suggested in comment #7

The build completes in mock on FC5, x86_64.  However, things don't look right in
the built package:

lrwxrwxrwx    1 root    root               33 May 11 15:10 /usr/bin/gprolog ->
../lib/gprolog-1.2.19/bin/gprolog
-rwxr-xr-x    1 root    root           864648 May 11 15:10
/usr/lib64/gprolog-1.2.19/bin/gprolog

That link seems to be dangling.  The same for all of the links in the
gprolog-compiler package.

I didn't want to urge you to split off the compiler package. In fact
after looking at it, I would say it would be better not to do it.
As for the case of x86_64, I think we should let the build be in /usr/lib.
Otherwise it may mean patching Makefiles to use the correct path (possibly
the %prefix/lib dir is hardcoded somewhere. If it is easy to fix, do it.

I have revert to:

SPEC: http://www.herr-schmitt.de/pub/gprolog/gprolog.spec
SRPM: http://www.herr-schmitt.de/pub/gprolog/gprolog-1.2.19-4.src.rpm

Please approve the package or tell me, waht I have to do to get the package aprove.

It seems to me that the pdf files compil-scheme.pdf and debug-box.pdf
should not be included in the docs, since they are graphics that are
already included in the manual.

Otherwise seems good to me.

APPROVED