Bug 211623 - Review Request: libtcd - Tide Constituent Database Library
Review Request: libtcd - Tide Constituent Database Library
Status: CLOSED DUPLICATE of bug 211626
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On:
Blocks: 211625
  Show dependency treegraph
 
Reported: 2006-10-20 10:45 EDT by Mamoru TASAKA
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-10-21 07:12:05 EDT
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 Mamoru TASAKA 2006-10-20 10:45:03 EDT
Spec URL: http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/libtcd.spec
SRPM URL: http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/libtcd-2.1.3-1.src.rpm
Description: 
The Tide Constituent Database (TCD) file format and schema are 
used by XTide to retrieve constituent definitions 
(speeds, equilibrium arguments, and node factors), harmonic 
constants, subordinate station offsets and associated metadata 
for use in generating tide predictions.


NOTE:
The source code is in xtide, however, I split this (libtcd) out
because other utilities can use this.
Comment 1 Patrice Dumas 2006-10-20 15:55:14 EDT
Why not jusut do a subpackage of xtide? Why split the source?
Comment 2 Michael Schwendt 2006-10-20 16:30:30 EDT
Several issues:

* First of all, I don't think this split-off is convenient. It increases
maintenance requirements with questionable benefit:

 - upstream do not ship libtcd in a separate tarball
 - you include the xtide tarball in two src.rpms
 - you introduce an own SONAME and ABI
 - you can update xtide without building an included newer libtcd

As long as upstream doesn't treat libtcd as a separate release, why
don't you build packages "libtcd", "libtcd-devel" and "tcd-utils"
from inside the xtide src.rpm instead?

What other programs want libtcd?


* Versioning:

> +SOMAJOR = 21
> +SOMINOR = 0
> +SOVER   = 3

Upstream uses MAJOR_REV 2 and MINOR_REV 1. Where does your versioning
scheme originate? As long as upstream uses only static libs, do you want
to increase major/minor/release appropriately?


* Shipping the headers in standard search path pollutes the global
namespace with generic file names. Much better would be to install them
into %_includedir/libtcd/

$ rpmls -p libtcd-devel-2.1.3-1.i386.rpm 
-rw-r--r--  /usr/include/nvtypes.h
-rw-r--r--  /usr/include/tcd.h
-rw-r--r--  /usr/include/tide_db_default.h
-rw-r--r--  /usr/include/tide_db_header.h
-rw-r--r--  /usr/include/tide_db_version.h
lrwxrwxrwx  /usr/lib/libtcd.so
drwxr-xr-x  /usr/share/doc/libtcd-devel-2.1.3
-rw-r--r--  /usr/share/doc/libtcd-devel-2.1.3/libtcd.html


* Hint:

>	ln -sf $f $RPM_BUILD_ROOT%{_libdir}/`echo $f | sed -e 's|.[^.][^.]*.[^.][^.]*$||'`
>	ln -sf $f $RPM_BUILD_ROOT%{_libdir}/`echo $f | sed -e 's|.so.*$|.so|'`

You could simply run

  cd $RPM_BUILD_ROOT%{_libdir}
  ln -s libtcd.so.* libtcd.so
  /sbin/ldconfig -n $(pwd)
  cd -

which would be much easier to the eyes.
Comment 3 Mamoru TASAKA 2006-10-20 19:02:20 EDT
(In reply to comment #2)
> Several issues:
> 
> * First of all, I don't think this split-off is convenient. It increases
> maintenance requirements with questionable benefit:
> 
>  - upstream do not ship libtcd in a separate tarball
>  - you include the xtide tarball in two src.rpms
>  - you introduce an own SONAME and ABI
>  - you can update xtide without building an included newer libtcd
> 
> As long as upstream doesn't treat libtcd as a separate release, why
> don't you build packages "libtcd", "libtcd-devel" and "tcd-utils"
> from inside the xtide src.rpm instead?
> 
> What other programs want libtcd?
libtcd is also required by harmbase2 (I don't know well this package and
I have not yet made srpm for this) in 
http://www.flaterco.com/xtide/libtcd.html. 

In this html, upstream considers the case that people want to seperate libtcd.
And upstreams of libtcd and xtide are different......

I don't think that including tcd-utils and xtide in same srpm is
proper because I have to recompile both even if I want to apply a 
patch for one of the packages and have to bump release.

> 
> 
> * Versioning:
> 
> > +SOMAJOR = 21
> > +SOMINOR = 0
> > +SOVER   = 3
> 
> Upstream uses MAJOR_REV 2 and MINOR_REV 1. Where does your versioning
> scheme originate? As long as upstream uses only static libs, do you want
> to increase major/minor/release appropriately?

Having MAJOR 2 and MINOR 1 means "libtcd.2.0 and libtcd.2.1 are API
compatible. However, as far as I read libtcd.html, it is NOT!!

Anyway, before fixing packaging xtide related packages, we must
decide if we should split libtcd (I think should).  This issue
affect the whole scheme of packaging xtide.
Comment 4 Mamoru TASAKA 2006-10-20 19:04:29 EDT
Oops...
harmbase2 is under http://www.flaterco.com/xtide/files.html .

And you can browse libtcd.html on
http://www.flaterco.com/xtide/libtcd.html
Comment 5 Michael Schwendt 2006-10-20 19:59:01 EDT
> And upstreams of libtcd and xtide are different......

No, David Flater is the maintainer of both.

> In this html, upstream considers the case that people want to
> seperate libtcd.

Because libtcd and everything around TCD is in the PD, while
xtide is GPL. Hence libtcd comes with an own configure script,
which makes it possible to build the library separately.

Still, upstream does not ship a shared library, maybe never will do so.

[...]

How does the DSO versioning scheme you've invented relate to libtcd's
versioning scheme?

Where do you see that libtcd 2.0 and 2.1 are incompatible?

With every update of xtide, will you check whether the included libtcd
contains changes? And then split it off, build the library packages first,
and only then build utils and xtide?
Comment 6 Mamoru TASAKA 2006-10-20 20:49:50 EDT
(In reply to comment #5)
> No, David Flater is the maintainer of both.
Actually you are true.

> 
> > In this html, upstream considers the case that people want to
> > seperate libtcd.
> 
> Still, upstream does not ship a shared library, maybe never will do so.
However providing shared library, not static is preferable.

> How does the DSO versioning scheme you've invented relate to libtcd's
> versioning scheme?
Sorry, but what is "DSO"? 
> 
> Where do you see that libtcd 2.0 and 2.1 are incompatible?
I have re-checked the header files and they are _COMPATIBLE_ .
I agree with the name libtcd.so.2.1.3 .
 
> With every update of xtide, will you check whether the included libtcd
> contains changes? 
Of course. Actually some changes have occured with xtide without
the part of libtcd unchanged.

> And then split it off, build the library packages first,
> and only then build utils and xtide?

I think this is not a bad idea.

Comment 7 Mamoru TASAKA 2006-10-21 03:10:25 EDT
By the way, "all in once" srpm and spec file are:

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/xtide-unified.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/xtide-2.9-0.2.dev20061015.src.rpm

(for a moment the name of spec file is changed so that you can see
  both (i.e. "seperated" type and "unified" type) with browser ).

This spec file enables the switch about whether we build libtcd.so or not.
Comment 8 Patrice Dumas 2006-10-21 04:10:36 EDT
> Sorry, but what is "DSO"? 

I guess it is dynamically share object or something along.

> > Where do you see that libtcd 2.0 and 2.1 are incompatible?
> I have re-checked the header files and they are _COMPATIBLE_ .
> I agree with the name libtcd.so.2.1.3 .

This soname look too much like the version of the library. In
general it is wrong. I'll have a look at the code, however, to be 
sure.


Comment 9 Michael Schwendt 2006-10-21 04:42:25 EDT
> libtcd.so.2.1.3

And with libtcd 2.1.4 the soname would become libtcd.so.2.1.4 and would
break the ABI, which in turn would require a rebuild of tcd-utils and
xtide.

The reason I'm questioning this library split-off is that it is
half-baked.
Comment 10 Mamoru TASAKA 2006-10-21 07:12:05 EDT
Well, unifying to xtide.

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

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