Red Hat Bugzilla – Bug 211623
Review Request: libtcd - Tide Constituent Database Library
Last modified: 2007-11-30 17:11:46 EST
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.
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 ***