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: subversion-api-docs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177483 toshio@xxxxxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|gdk@xxxxxxxxxx |toshio@xxxxxxxxxxxxxxx ------- Additional Comments From toshio@xxxxxxxxxxxxxxx 2006-03-06 03:14 EST ------- Good: * Naming guidelines: the name of the source is subversion. This package is intended as an addon to the Core subversion package using the Core subversion headers (in subversion-devel) to generate its content. Thus the name looks like a subpackage of subversion. * spec file name matches package name * OSI approved license (BSD) * LICENSE text is included in the subversion package which is required by this package. As it's intended as an addon to the Core package extracting its content from the actual Core headers this seems acceptable to me. * Package is legible and in American English * Builds successfully on FC4 using version 1.2.3 instead of 1.3.0 * No excluded BuildRequires * All necessary BuildRequires provided. * No locales * No shared libraries * Not relocatable * Owns all directories it creates * No duplicate files * Correct permissions * %clean's the buildroot * Uses consistent macros * Permissible content: API documentation for a packaged library. * Does not own directories owned by other packages. Needswork: * Does the subversion-api-docs-doxygen.conf file come from upstream somewhere? Is it in their distributed tarball? Having a URL to the file would be good -- perhaps a link into their subversion repository for the %{version} tag? Needs addressing: * If we do treat this as a pseudo-subpackage of Core's subversion, then we need to make these changes: - Requires should be on subversion rather than subversion-devel - BuildRequires subversion-devel and the Requires should require the full EVR: BuildRequires: subversion-devel = %{version}-%{release} Requires: subversion = %{version}-%{release} This leads into my concern, however: - How are you going to keep this package synced up with Core's subversion? To do this right, you need to create a new version whenever Core releases an updated subversion package. Otherwise there will be unresolved dependencies between Core and Extras that prevent people from upgrading. This isn't a hard thing to do, but it is time critical. Let's say there's a security bug in neon that requires apps to be recompiled against the new neon library. This affects subversion, ethereal, and openoffice.org among others. These packages are recompiled aainst the new library and released. But because people have the subversion-api-docs package installed which hasn't been upgraded yet, yum refuses to upgrade them and people are left vulnerable until we rebuild subversion-api-docs against the new subversion. - "Large documentation files should go in a -docs subpackage." If these files were created as a subpackage of the Core subversion package they would likely just be included as %doc in a subpackage. They wouldn't be specially installed into the main subversion package's doc directory. So it seems much more graceful to install this into it's own documentation directory and not have a Requires: on subversion or subversion-devel. The API documentation can get out of sync with the installed subversion, then, but it seems preferable to blocking upgrading in case of security releases or the like. - We would want to include a copy of subversion's LICENSE in this case. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
