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=732205
--- Comment #2 from Denis Arnaud <denis.arnaud_fedora(a)m4x.org> 2011-08-21 07:16:02
EDT ---
(In reply to comment #1)
Some quick comments:
Thanks for the comments/feedback!
Drop the README file, as it only contains instructions on how to
install.
I take it as an encouragement to put more project description into the README
:)
The doc package should require the base package.
AFAIK, that is not a requirement
(
https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation and
https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package).
Indeed, it makes sense to install a doc sub-package without having to install
the base package, for instance if you just want to read the documentation
before hacking with the software.
Drop COPYING from the doc sub-package, as the base package provides
it.
Well, you are right when the -doc sub-package depends on the base package. In
my case, as the -doc sub-package does not require the base package, it is part
of the exception and the license file has to be repeated (see
https://fedoraproject.org/wiki/Packaging/Guidelines#Duplicate_Files and
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_L...).
"This package contains the documentation in the HTML format of
the %{name}
library." -- That's probably not perfect English.
Thanks. I have re-worded it as following:
"This package contains HTML pages, as well as a PDF reference manual,
for %{name}. All that documentation is generated thanks to Doxygen
(
http://doxygen.org). The content is the same as what can be browsed
online (http://%{name}.org)."
Your devel sub-package does not contain static libraries, as the
description
claims.
Thanks. I have re-written it:
"This package contains the header files, shared libraries and
development helper tools for %{name}. If you would like to develop
programs using %{name}, you will need to install %{name}-devel."
State BuildRequires per package -- not per sub-package.
AFAIK, there is no such requirement from the guidelines
(
https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires). So, it is
a question of taste, then (for instance, many legitimate packages are like mine
in Fedora). I personally prefer stating the BR in the sub-packages where they
are required (e.g., the doxygen BR comes from the documentation package
generation).
The two chmods serve no purpose.
You are absolutely right. Since I am also part of upstream, it would not have
been clever to fix the file permissions only at the time of packaging, would
it?
I have removed the corresponding two lines.
You can use the name macro on this line: %{_libdir}/lib*.so.*
You are right. It is safer to be explicit (and, in the present case, more
consistent with the -devel sub-package specification).
You're packaging manpage 1 twice.
Unless I have missed something obvious,
* one section-1 manual page is for the main (ELF) binary, namely 'airsched';
* while the other section-1 manual page is for the (Shell) configuration
helper, namely 'airsched-config'.
The latter manual page is in the -devel sub-package because it servers only the
needs of developers using AirSched.
I think, you don't have to package the m4 file.
You are right: I do not have to. But I do not want to force everybody to use
CMake and/or pkgconfig. Typically, developers, building their own software with
the GNU Autotools on top of AirSched, will need an airsched.m4 file. Note that
mine is probably far from perfect; but I would say "it is better than nothing"
for those needing such a thing (in my team, for instance, we needed it for a
long time... before switching to CMake).
"Install the %{name} package if you need a library for simulated
Schedule
Management C++ library." -- A library for a library?
Thanks. I have re-worded it:
"Install the %{name} package if you need a library of basic C++ objects
for Airline Schedule Management, mainly for simulation purpose."
---------------
I shall very shortly publish the new specification file (and source RPM) URLs.
--
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.