[Bug 211626] Review Request: xtide - Calculate tide all over the world

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: xtide - Calculate tide all over the world


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211626





------- Additional Comments From pertusus at free.fr  2006-10-31 08:23 EST -------
(In reply to comment #74)
> Have any of you two perused the Debian packaging work?
> http://ftp.debian.org/debian/pool/main/x/xtide/xtide_2.8.2-3.diff.gz

The patches seem not to be relevant in the cvs snapshot anymore.
It is not easy to use the debian stuff since their patch patches
the code directly. However it should be very relevant to work
together with debian people on that package. For example we could
use their harmonics data, and they will certainly benefit from
what is done on the fedora package, for example the wrappers.

Mamoru, you should certainly contact them to ask them to rearrange
their debian patchset such that the patches are applied as part of
the rules, and not directly such that you can apply it simply to
xtide in spec.

> Surprise, surprise, it's an all-in-one package. Except for wvs-data,
> which they ship as an optional xtide-data (trimmed down by 7M). They
> include a minimal set of harmonics data, btw.

I don't see the wvs data in the xtide-data package, it seems to me that
it contains only harmonics, and in the debian help files it is mentionned
that wvs-data is too big to be uploaded in debian. I don't see tideEditor
in debian either.

> [...]
> 
> Upstream's requirement to break the ABI/API so soon after you had
> created a shared library forces libtcd to become static. Unless you
> try to talk to David Flater about whether maybe he accepts patches
> and what he thinks about separating libtcd into a separate tarball.
> 
> tideEditor makes only sense to be put into an own sub-package if you
> insist on doing that because of its Qt requirement. However, it does
> not make sense to merge it with tcd-utils or to put the small utils
> into a separate package when a) you include them in the xtide src.rpm
> anyway and b) they are linked statically.

I agree with both remarks. 

(In reply to comment #73)
> Well, then what blocks this for now is:
> 
> 0. First of all, should we split files related to "this" src package
>    to several binary packages?
> 
> A. should we provide libtcd (and libtcd-devel) packages for now, or
>    use static libtcd.a?
> 
> A-1 If we should provide libtcd dynamic library, how we should decide
>          soname versioning? 
> A-2 Is this be discussed with upstream [before/after]
>          releasing this to Fedora Extras?

I think we should release dynamically linked binaries, but after having
upsteram accept the soname naming and the build patches.

> B. To what component should tideEditor belong to? 
> 
> B-1 Also, should the discussion of tideEditor assignment be discussed 
>      with upstream [before/after] releasing to Fedora Extras?
> 
> Is it okay?

Not exactly. In my opinion there are 2 issues that are distinct:

1) the split of the source package. It is to be done upstream, and, to
repeat myself I think the current split is broken, tideEditor should be
with xtide, while libtcd should be split out with the *tide_db.

I think that this should be discussed with upstream.

2) the split of the rpm binary packages. This is our task, here, and 
somehow independent from the choices done upstream, in case we have only
one src.rpm as it is the case for now.

Regarding this issue, I am fine with a all-in-one package, but I am also
fine with a split package. Indeed, having subpackages for libtcd(-devel)
is fine by me since makes sense to build other software against that 
library. The *tide_db convertors may be in the libtcd package, but then,
unless I'm wrong it won't be possible to be multilib. So they could also
be in a standalone package (tcd-utils) or included with a big xtide package.
I wouldn't object to a separate xttpd package because I think that it is 
right to have the choice to install a network daemon or not. I am also 
fine with a separate package for tideEditor because of the huge dependency.
If xttpd/tideEditor/xtide are not in the same package, then a -common
subpackage is also needed for the conf file and harmonics (real files or
instructions).

I am open to any combination implied by the above, I think they all make 
sense, and it should be left to Mamoru to chose, but not in a hurry, please.

My personal choice would depend on upstream. If upstream agrees with 
dynamic library, and split the source as I advertise above I would 
go for libtcd, libtcd-devel, tcd-utils (only with *tide_db 
convertors) and a xtide package with the remaining. If upstream don't 
put the *tide_db in a separate package, I would go for libtcd, 
libtcd-devel and all the remaining grouped together. And if upstream
don't want dynamic libtcd, I would go for a all-in-one package.

The current situation with tideEditor packaged only with the *tide_db 
convertors seems wrong, however.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.