Bug 517550

Summary: Packaging issues with gnustep-make
Product: [Fedora] Fedora Reporter: Charles Lopes <tjarls>
Component: gnustep-makeAssignee: Axel Thimm <Axel.Thimm>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: Axel.Thimm, michel
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 523018 Environment:
Last Closed: 2009-09-13 17:30:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Changes to gnustep-make.spec none

Description Charles Lopes 2009-08-14 15:23:56 UTC
Created attachment 357467 [details]
Changes to gnustep-make.spec

I have found some issues with version 2.0.8-2 of gnustep-make:

* The LOCAL and SYSTEM domains are the same. By default a "make install" will use the LOCAL domain (/usr/local) but with this package the installation will end up under /usr (the SYSTEM domain). This is a deviation from upstream introduced by some mangling in the spec file.

* Variable GNUSTEP_SYSTEM_DOC is set to /usr/share/doc/gnustep-make-doc-2.0.8. This will cause other GNUstep software installed with this version of gnustep-make to install their respective documentation in that directory. This is another mangling introduced in the spec file.

* gnustep-make installs info pages whose name is far too generic: faq.info, filesystem.info, machines.info, userfaq.info. Installing these should be avoided until they get renamed upstream.

* The spec file is broken when build without docs because there is still a "%files doc" section. It should be within a if statement.

I am attaching a diff file with proposed changes to the spec file.

Comment 1 Michel Lind 2009-09-13 17:30:21 UTC
I've fixed most (all?) of this in my 2.2.0 -- making this bug a duplicate of that. Charles, thanks for the inputs -- please carry on the discussion over there.

*** This bug has been marked as a duplicate of bug 523018 ***