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@xxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review