Why not jusut do a subpackage of xtide? Why split the source?

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.

(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.

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

> 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?

(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.

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.

> 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.

> 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.

Well, unifying to xtide.

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