Bug 187266 - Review Request: gprolog - GNU Prolog is a free Prolog compiler
Review Request: gprolog - GNU Prolog is a free Prolog compiler
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gérard Milmeister
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-03-29 12:45 EST by Jochen Schmitt
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-17 10:08:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jochen Schmitt 2006-03-29 12:45:45 EST
Spec Name or Url: http://www.herr-schmitt.de/pub/gprolog/gprolog.spec
SRPM Name or Url: http://www.herr-schmitt.de/pub/gprolog/gprolog-1.2.19-1.src.rpm

Description:
GNU Prolog is a native Prolog compiler with constraint solving over
finite domains (FD) developed by Daniel Diaz
(http://loco.inria.fr/~diaz).
Comment 1 Jason Tibbitts 2006-03-29 13:34:10 EST
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 2 Gérard Milmeister 2006-03-29 14:08:48 EST
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.
Comment 3 Jochen Schmitt 2006-03-29 14:56:12 EST
The patches are coming from the gentoo project.
Comment 4 Jochen Schmitt 2006-03-30 10:48:03 EST
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
Comment 5 Gérard Milmeister 2006-04-01 13:27:35 EST
(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!
Comment 7 Gérard Milmeister 2006-05-10 16:28:32 EDT
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.
Comment 8 Jochen Schmitt 2006-05-11 12:41:51 EDT
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

Comment 9 Jason Tibbitts 2006-05-11 16:08:05 EDT
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.

Comment 10 Gérard Milmeister 2006-05-11 16:59:56 EDT
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.
Comment 11 Jochen Schmitt 2006-05-14 14:05:21 EDT
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.

Comment 12 Gérard Milmeister 2006-05-14 16:21:32 EDT
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

Note You need to log in before you can comment on or make changes to this bug.