Bug 450050 - Review Request: cgilib - A C library for creating Common Gateway Interface ("CGI") programs
Summary: Review Request: cgilib - A C library for creating Common Gateway Interface ("...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lucian Langa
QA Contact: Fedora Extras Quality Assurance
: 511387 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-04 22:50 UTC by W. Michael Petullo
Modified: 2013-02-19 10:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-02-19 10:59:52 UTC
Type: ---
lucilanga: fedora-review?

Attachments (Terms of Use)

Description W. Michael Petullo 2008-06-04 22:50:31 UTC
Spec URL: http://www.flyn.org/SRPMS/cgilib.spec
SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.6-1.fc9.src.rpm
The cgilib library provides a C library for creating Common Gateway
Interface (CGI) programs.  The CGI is a way to create dynamic web pages.
It defines rules for interaction between a program and the web server
while the server talks to the client.

Comment 1 Jason Tibbitts 2008-06-06 20:04:31 UTC
This fails to build in mock for me:

+ aclocal
/var/tmp/rpm-tmp.72081: line 30: aclocal: command not found
error: Bad exit status from /var/tmp/rpm-tmp.72081 (%build)

If you're going to run the autotools, you at least need to have a build
dependency on them.

The autotools patch seems significant, renaming a bunch of documentation files.
 Is there any point to it?  It seems like a gratuitous difference from upstream.

Comment 2 W. Michael Petullo 2008-06-09 23:45:03 UTC
Spec URL: http://www.flyn.org/SRPMS/cgilib.spec
SRPM URL:http://www.flyn.org/SRPMS/cgilib-0.6-2.fc9.src.rpm

This version simplifies the autotools patch. It no longer attempts to conform to GNU's standards. The 
package also now BuildRequires the autotools programs.

Comment 3 Lucian Langa 2008-11-14 17:34:43 UTC
%files for the -devel package has no %defattr

cgilib.x86_64: W: file-not-utf8 /usr/share/doc/cgilib-0.6/readme
The character encoding of this file is not UTF-8.  Consider converting it in
the specfile's %prep section for example using iconv(1).

please also consider preserve installed and/or modified files timestamps:

 - above iconv operation
 - make install target

please explain why do you need to use autotools patch.
You need to contact upstream for such modifications, anyway it should not be handled in the spec file.
As I see it radically changes the source package.

Comment 4 Jason Tibbitts 2008-12-20 21:13:10 UTC
Any update?  It's been over a month since the last comment.

Comment 5 W. Michael Petullo 2008-12-21 14:52:04 UTC
I am working to get the autotools patch upstream.

Comment 6 Jason Tibbitts 2008-12-21 20:48:52 UTC
Please clear the whiteboard when you believe this is ready for a review.

Comment 7 W. Michael Petullo 2009-02-10 02:20:29 UTC
Cgilib 0.7 was just released with the autotools patch applied:

Spec URL: http://www.flyn.org/SRPMS/cgilib.spec
SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.7-1.fc10.src.rpm

Comment 8 Lucian Langa 2009-02-10 05:50:19 UTC
I do not see rest of the points from comment #3 fixed.

Comment 9 W. Michael Petullo 2009-02-11 01:17:00 UTC
- Set defattr for devel package.
- Convert README to UTF-8 as original is ISO-8859 and has invalid characters.

Spec URL: http://www.flyn.org/SRPMS/cgilib.spec
SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.7-2.fc10.src.rpm

Comment 10 Lucian Langa 2009-03-06 19:14:30 UTC
Sorry for the late reply.
There are a few problems with this package:

1. The same functionality this package provides is offered by a package already in Fedora libcgi, moreover the library cgilib provides conflicts with the library from libcgi. Library name has to be renamed one suggestion could be libcgilib.

2. Header files (aux and cgi) are too generic to be placed in {_includedir}. They need to be placed under a subdirectory (cgilib) of {_includedir}.

Comment 11 Jason Tibbitts 2009-07-14 21:41:38 UTC
*** Bug 511387 has been marked as a duplicate of this bug. ***

Comment 12 Jason Tibbitts 2009-07-14 21:43:01 UTC
Could someone update the status of this ticket?  It's been idle for quite some time and now someone else has submitted cgilib for review.

Comment 13 Gary T. Giesen 2009-07-17 15:57:16 UTC
Sent an email privately to W. Michael Petullo (mike), no response in two days.

Comment 14 Jason Tibbitts 2009-07-17 16:43:57 UTC
If there's no response by Jul 21 (one week after my ping) then I'll reopen Gary's ticket and close this one.

Comment 15 W. Michael Petullo 2009-07-17 23:57:07 UTC
Regarding reopening #511387, that's fine. I pushed hard for a while to get this in Fedora. In fact, I wrote the original autotools patch and helped the upstream maintainer with autotools before he integrated the patch for 0.7. That being said, I do not have a good solution to the issues raised on the fedora-packaging mailing list; see:



> Unrelated to this, libcgi maintainer should not have chosen to use libcgi.so.1 as the 
> soname without upstream's approval.
    -- Mr. Mierzejewski (later in this mail thread)

Progress was stuck because 1) I don't think that we should ship a shared library name that is different that what upstream intends 2) we can't have two packages with the same shared library name and 3) I did not feel like asking the developer to rename his project due to one distribution's preferences.

I'd like to see cgilib packaged. I just did not have the time to work through this. I did invest a lot of time to get my autotools work in, so I would like to cgilib in Fedora eventually.

Comment 16 Gary T. Giesen 2009-07-18 02:07:56 UTC
I'm not an experienced enough packager to know what the right solution is. I would like to see cgilib included, as I have another package (in fact, the reason I became a Fedora packager) that depends on it, yet I don't want to package this incorrectly. The package I created was based on the guidelines at https://fedoraproject.org/wiki/Packaging:Conflicts#Library_Name_Conflicts , but obviously that is too simplistic for this case. Where do we go from here?

Comment 17 Miroslav Suchý 2012-12-16 12:43:20 UTC
Ping? Any progress here? Or we can close this review?

Comment 18 Miroslav Suchý 2013-02-19 10:59:52 UTC
Stalled Review. Closing per:
If you ever want to continue with this review, please reopen or
submit new review.

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