[Bug 177483] Review Request: subversion-api-docs

[bugzilla at redhat.com]

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 at tiki-lounge.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gdk at redhat.com              |toshio at tiki-lounge.com




------- Additional Comments From toshio at tiki-lounge.com  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.