Bug 450050

Summary: Review Request: cgilib - A C library for creating Common Gateway Interface ("CGI") programs
Product: [Fedora] Fedora Reporter: W. Michael Petullo <mike>
Component: Package ReviewAssignee: Lucian Langa <cooly>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: cooly, fedora-package-review, ggiesen+redhat, msuchy, notting
Target Milestone: ---Flags: cooly: fedora‑review?
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-19 05:59:52 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    

Description W. Michael Petullo 2008-06-04 18:50:31 EDT
Spec URL: http://www.flyn.org/SRPMS/cgilib.spec
SRPM URL: http://www.flyn.org/SRPMS/cgilib-0.6-1.fc9.src.rpm
Description:
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 16:04:31 EDT
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 19:45:03 EDT
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 12:34:43 EST
%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 16:13:10 EST
Any update?  It's been over a month since the last comment.
Comment 5 W. Michael Petullo 2008-12-21 09:52:04 EST
I am working to get the autotools patch upstream.
Comment 6 Jason Tibbitts 2008-12-21 15:48:52 EST
Please clear the whiteboard when you believe this is ready for a review.
Comment 7 W. Michael Petullo 2009-02-09 21:20:29 EST
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 00:50:19 EST
I do not see rest of the points from comment #3 fixed.
Comment 9 W. Michael Petullo 2009-02-10 20:17:00 EST
- 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 14:14:30 EST
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 17:41:38 EDT
*** Bug 511387 has been marked as a duplicate of this bug. ***
Comment 12 Jason Tibbitts 2009-07-14 17:43:01 EDT
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 11:57:16 EDT
Sent an email privately to W. Michael Petullo (mike@flyn.org), no response in two days.
Comment 14 Jason Tibbitts 2009-07-17 12:43:57 EDT
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 19:57:07 EDT
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:

https://www.redhat.com/archives/fedora-packaging/2009-February/msg00047.html

especially:

> 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-17 22:07:56 EDT
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 07:43:20 EST
Ping? Any progress here? Or we can close this review?
Comment 18 Miroslav Suchý 2013-02-19 05:59:52 EST
Stalled Review. Closing per:
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
If you ever want to continue with this review, please reopen or
submit new review.