Bug 213859 - tre-devel package does not contain static libraries
tre-devel package does not contain static libraries
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: tre (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dominik 'Rathann' Mierzejewski
Fedora Extras Quality Assurance
:
: 213857 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-03 09:37 EST by Nico Kadel-Garcia
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-06 13:38:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nico Kadel-Garcia 2006-11-03 09:37:15 EST
Description of problem:
tre-devel package does not contain static libraries

Version-Release number of selected component (if applicable):
tre-0.7.4

How reproducible:
Run
   rpm -ql tre-devel
on any default installed tre-devel RPM.

Steps to Reproduce:
1. Install tre-devel RPM with yum install tre-devel.
2. Check contents with rpm -ql tre-devel
3.
  
Actual results:


Expected results:
There should be a libtre.a file included.

Additional info:
This is easily fixed by adding the --enable-static option to the %configure in 
the .spec file, and adding %{_libdir}/libtre.a to the list of files for the -
devel package. I've contacted the software author, but he's in no rush to 
publish a new .spec file update.
Comment 1 Dominik 'Rathann' Mierzejewski 2006-11-03 13:06:30 EST
*** Bug 213857 has been marked as a duplicate of this bug. ***
Comment 2 Dominik 'Rathann' Mierzejewski 2006-11-03 13:11:06 EST
Shipping static libraries is forbidden by current Fedora Extras Packaging
Guidelines:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-2302ec1e1f44202c9cc4bcce24cb711266557ad7
and is allowed only in exceptional circumstances. Why do you think such
circumstances exist in this case?
Comment 3 Nico Kadel-Garcia 2006-11-03 14:55:43 EST
Interesting: I hadn't realized they were excluded by policy. Thanks for the 
pointer.

The reason I was pursuing it was for CRM114 bundling: there have been some 
subtle bugs in older versions of TRE that had to be repaired to operate 
correctly with CRM114, and the author of CRM114 thus strongly prefers it be 
bundled as a static package. That means either building TRE locally, or 
including the static libraries as part of the tre-devel package. And I *HATE* 
having to build such tools locally.
Comment 4 Toshio Kuratomi 2006-11-03 18:45:08 EST
Note: I don't user tre or crm114, I'm just part of the packaging committee.  So
you may have to explain somethings if I'm too ignorant :-)

What are you doing that you need to rebuild crm114?
Why can't crm114 specify a minimum version of tre in it's configure/build script?
Is there a reason that bundling crm114 with the known shared version of tre
doesn't work?
Comment 5 Nico Kadel-Garcia 2006-11-04 12:35:38 EST
I'm trying to get it autonf-iscated, and RPM bundled with the author's 
cooperation. *Minimum* version of tre is not the issue: since it's not 
completely stable, the author of CRM114 has been very reluctant to use the 
dynamic libraries with it. I'm trying to talk him out of compiling it himself 
as part of his build process, and to use the "extras" package instead for RPM 
bundling.

It's cool, I'll negotiate it with him ASAP to avoid relying on such static 
libraries.
Comment 6 Dominik 'Rathann' Mierzejewski 2006-11-06 05:40:52 EST
(In reply to comment #5)
> I'm trying to get it autonf-iscated, and RPM bundled with the author's 
> cooperation. *Minimum* version of tre is not the issue: since it's not 
> completely stable, the author of CRM114 has been very reluctant to use the 
> dynamic libraries with it.

That is simply not true. According to the author the ABI can be considered
stable and there are no plans to make incompatible changes to libtre.

> I'm trying to talk him out of compiling it himself as part of his build
> process, and to use the "extras" package instead for RPM bundling.

IMHO it's perfectly safe to do that.

> It's cool, I'll negotiate it with him ASAP to avoid relying on such static 
> libraries.

OK to close this, then?
Comment 7 Nico Kadel-Garcia 2006-11-06 13:25:20 EST
OK, that's good. I was working from the CRM114 author's desires, not the TRE
author's stated plans. It sounds good: let's close it.

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