Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 187266 - Review Request: gprolog - GNU Prolog is a free Prolog compiler
Summary: Review Request: gprolog - GNU Prolog is a free Prolog compiler
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gérard Milmeister
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-03-29 17:45 UTC by Jochen Schmitt
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-17 14:08:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jochen Schmitt 2006-03-29 17:45:45 UTC
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 18:34:10 UTC
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 19:08:48 UTC
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 19:56:12 UTC
The patches are coming from the gentoo project.

Comment 4 Jochen Schmitt 2006-03-30 15:48:03 UTC
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 18:27:35 UTC
(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 20:28:32 UTC
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 16:41:51 UTC
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 20:08:05 UTC
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 20:59:56 UTC
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 18:05:21 UTC
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 20:21:32 UTC
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.