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(a)free.fr 2006-10-31 08:23 EST -------
(In reply to comment #74)
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.