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 dave@xxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dave@xxxxxxxxxxxx ------- Additional Comments From dave@xxxxxxxxxxxx 2006-11-12 20:38 EST ------- Upstream here. I was AFK for two weeks. In a message dated 2006-11-02 19:47+0900, Mamoru Tasaka wrote: > A. > Well, currently libtcd library are packaged in XTide tarball and > only static archive are provided. libtcd is used not only for XTide, > but also some utilities in tcd-utils and others, so I think > providing libtcd seperately is a good idea. The reason things are packaged the way they are is that 99% of users are only interested in running XTide to get tide predictions. They have no interest in nor any need for an ability to generate or edit the tide data, and anything I do to make that possible for them just adds complexity, hurts performance, and makes them yell at me. I have been there and done that, and it was a mistake. tcd-utils is for the other 1% who actually do know enough to edit tide data in a meaningful way and have reason to do it. It was never cleaned up for the 99% market. The people who use it (counted on one hand) have never complained about having to compile it from ugly source snapshots. The inclusion of tcd-utils in Fedora was perhaps motivated by some policy that discouraged shipping binary files? For the legacy harmonics data (still distributed by Bob Kenney, but not maintained), the TCD was in fact built from text and XML source, so building a TCD using tcd-utils might have made sense. But that is all ancient history. harmonics-dwf now starts with scraping web pages from the NOAA web site using software that has to be updated every year as their web site changes, then these are processed into an SQL database where they merge with other countries' data, then manual fixes are made as needed to correct upstream errors, then eventually the whole mess is exported directly to TCD. The closest you could get to what you want is to start with the SQL dump, but then you would need to have PostgreSql running, and harmbase2, and ... just don't go there. 99% of users will not benefit from this approach. They just want the tide prediction part of the program to install easily and run easily. I don't advise use of the legacy data. harmonics-dwf from http://www.flaterco.com/xtide/files.html is maintained by me. The legalese for harmonics-dwf is at http://www.flaterco.com/xtide/harmonics_boilerplate.txt. See http://www.flaterco.com/xtide/faq.html#60 for background on why there is so much of it. > A-1: How do you think of providing libtcd shared dynamic library seperately? This makes sense if you really do want to deliver tideEditor or other extras in Fedora. But do you *really* want to do that? > A-2: If you agree with provide libtcd.so, how should we determine soname? Deferred pending answers to previous. > A-3: Related to A-2, should we provide libtcd.so (if you agree) with COMPAT114 > defined or undefined? (Note: tcd-utils 2005-08-11 can _NOT_ be compiled > with COMPAT114 _defined_). Do not define COMPAT114. AFAIK only the Naval Oceanographic Office ever used this, and they might not even still use it. > A-4: Do you have any plan to provide seperate libtcd tarball? Deferred pending answers to previous. Separate maintenance of libtcd would help me in case libtcd needs maintenance when XTide doesn't, but for the 99% of users it would be an annoyance to have to do two installs instead of just one. FYI, the libtcd bundled in XTide 2.9 DEVELOPMENT incorporates bug fixes that are important ONLY to tideEditor, but for tideEditor they are serious. If Fedora wants to ship tideEditor as part of its distribution, then we (including me) need to do whatever is necessary to enable tideEditor to be linked with the newest libtcd, rather than the one that is bundled with the stable XTide 2.8.3. > B. > Another issue of packaging are tideEditor issue. The reviewers of XTide says > that tideEditor should belong to XTide package as: > * the other binaries in tcd-utils (build_tide_db and restore_tide_db) are only > command line conversion tools and have less dependency. > * on the other hand XTide, tideEditor is a graphical viewer (tideEditor is also > a viewer) and have a lot of dependency (especially tideEditor depends on Qt). > > So, > B-1: how do you think of moving tideEditor to XTide tarball? It would make sense if it were used by more than 1% of users. But I don't think that it is, or would be, even if it were installed for them automagically. It is only potentially useful if an end user manages to find some tide data that they want to add, and then only if they know what they are doing. This happy coincidence just doesn't happen as often as you would hope. FYI, I am currently in the midst of a 100% code review and cleanup for XTide. This is a good time to incorporate changes to make life easier for Fedora, but not a good time to assume that the latest snapshot is stable. Patrice Dumas wrote: > I guess that a full security audit of xttpd would be nice, however > it would go beyond a review. I will cooperate with a security audit of xttpd and implement any mitigations that are indicated, but if it does show any problems that are hard to address it might be better to retire it. I constructed xttpd as a proof-of-concept that you could put an HTTP interface on XTide, hoping that web developers would pick up the ball and run with it. They didn't. They preferred to stick with CGI, or nowadays with PHP. Other FYIs: With respect to patching configure to do CFLAGS etc. as expected, I have a guy who is supposedly reorganizing the whole thing according to current best practices and making it NetBSD-friendly. Haven't heard from him in a month or so, but I can put you in touch to coordinate changes. -- 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