[Bug 697326] Review Request: libisoburn - Library to enable creation and expansion of ISO-9660 filesystems

[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.


https://bugzilla.redhat.com/show_bug.cgi?id=697326

Michael Schwendt <mschwendt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |mschwendt at gmail.com
               Flag|                            |fedora-review+

--- Comment #11 from Michael Schwendt <mschwendt at gmail.com> 2011-10-05 05:48:48 EDT ---
* Wed Sep 28 2011 Release 1.1.6 : "libisoburn now comes with a test suite" -
that is just a file comparison executable to be run manually. It is not a full
suite that could be run in the %check section.

* Upstream offers a detached signature file that could be included
as another %{SOURCEn} file.

* A couple of packages in the distribution explicitly "Requires: util-linux",
but I don't think this should be added also for the xorriso kde helper, which
uses ionice.


> %global with_kde 1

More flexible would be

  %bcond_without kde

which by default would define %with_kde to 1 and undefine it if building
--without kde. The following conditionals,

> %if (%with_kde && 0%{?rhel}%{?fedora} > 5)

would need to be adjusted then, however. There are multiple solutions, such as

  %if %{with kde} && (0%{?rhel}%{?fedora} > 5)

or the more cryptic:

  %if 0%{?with_kde:1} && (0%{?rhel}%{?fedora} > 5)


> %package -n xorriso

I still think it should add an arch-specific base package dependency as
discussed before.
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package

And just to mention it, yes, it's possible to upgrade arbitrary libraries in
Fedora with API additions, (re)build applications with them and produce builds
where the automatic SONAME deps are not accurate enough. In a subpackage, one
has full control over the base package name and EVR, however, whereas an
explicit versioned dependency on external package NEVR bears risks.


* Unless you want to build this library for EPEL 5, you could prune some of the
items which are no longer necessary:
 - BuildRoot definition
 - BuildRoot removal at beginning of %install
 - %clean section
 - %defattr lines
 - pkgconfig dependency in -devel package


* APPROVED

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.