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 bugs.michael@xxxxxxx 2006-10-30 05:49 EST ------- The rationale behind the package split cannot be seen. First, multiple upstream packages are merged into a single source rpm just to distribute their contents to multiple rpms afterwards. What are the benefits of creating the sub-packages like this? Are package dependency requirements reduced? Is the size of the installation reduced? 1) As unfortunate as upstream's libtcd static library packaging inside xtide is, I understand that it makes sense to split off libtcd{-devel}, provided that at least another program is included with Fedora Extras (e.g. harmgen). The SONAME versioning scheme is unfortunate, but that is something to discuss with the upstream developer. 2) tcd-utils is a separate tarball, a small one, but needed for building your "xtide" rpms. So, you decided to include it, thereby defeating the purpose of the upstream split. Among other side-effects, you need to push new xtide, libtcd, libtcd-devel, xttpd, tcd-utils packages whenever one out of two upstream packages changes. Further, tideEditor, which is part of tcd-utils and not put into a separate rpm, adds a dependency on the rather large Qt. This reduces the benefit of a separate tcd-utils rpm, as now Qt is needed when installing the small *tide_db tools. 3) And finally, XTide, split into multiple small rpms, is "enhanced" with a strict dependency on a 40M data rpm. The current package split is neither obvious nor convenient for the users. Seriously, considering the special target group of XTide and friends, I wouldn't even mind an all-in-one package with *optional* data. -- 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