Spec URL: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils.spec SRPM URL: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils-0.2.1-1.fc13.src.rpm Description: Utility functions to manipulate file-system path names Koji scratch-build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2411651
This is an informal review, since I need a sponsor. I've identified some (little) issues: --- In the build logs: configure: WARNING: unrecognized options: --disable-rpath Not a serious issue, but you could safely remove this option --- Some BuildRequires may be useless here: autoconf, automake, libtool and m4 should not be necessary, since the ./configure script doesn't call any of these Autotools executables. --- rpmlint outputs look good : all false positives: libpath_utils-debuginfo.x86_64: W: spelling-error Summary(en_US) libpath -> lib path, lib-path, librate libpath_utils-debuginfo.x86_64: W: spelling-error Summary(en_US) utils -> utile, utilizes, utilize libpath_utils-debuginfo.x86_64: W: spelling-error %description -l en_US libpath -> lib path, lib-path, librate libpath_utils-debuginfo.x86_64: W: spelling-error %description -l en_US utils -> utile, utilizes, utilize libpath_utils-devel.x86_64: W: spelling-error Summary(en_US) libpath -> lib path, lib-path, librate libpath_utils-devel.x86_64: W: spelling-error Summary(en_US) utils -> utile, utilizes, utilize 5 packages and 0 specfiles checked; 0 errors, 6 warnings. --- COPYING file (with GPL) should not be delivered because this license only concerns the unit tests, not included in the binary packages.
The BuildRequires on autotools are there because autotools will sometimes internally detect during 'make' that the files need to be regenerated. (This can happen if the version of certain files is different on the build system) I didn't notice that --disable-rpath was ignored. That was left in there from the original package I split off from. Fixed. COPYING file must be included. COPYING.LESSER is a set of extensions to COPYING, not a complete license itself. Thank you for the review. New spec: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils.spec New SRPM: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils-0.2.1-2.fc13.src.rpm
I improved the description. New spec: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils.spec New SRPM: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils-0.2.1-3.fc13.src.rpm Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2412541
* source files match upstream: c54f32773a8c78c08340be330882fdb990cfb107 libpath_utils-0.2.1.tar.gz * package meets naming and versioning guidelines. * specfile is properly named and is cleanly written * specfile uses macros consistently. * summary is OK. * description is OK * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. (both of them) * latest version is being packaged. * BuildRequires are proper. * %clean is present. * package builds in mock (F-13, x86_64). * package installs properly * rpmlint is silent. * %check is present * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * documentation present in -devel package * %docs are set correctly APPROVED
Although this package quickly was approved, I still think the above-mentionned BuildRequires are still useless. If ./configure relaunches the autotools, it means that the configure.ac or Makefile.am files were more recent than it. This SHOULD not be the case, the developer MUST relaunchs the autotools to refresh the configure + Makefile.in files. So, since you seem to be also a developer of sssd, you must refresh these files instead of letting configure do the dirty job. You will certainly help packagers (and your potential co-mainteners!) to integrate and spread your stuff in other distributions... I'd like more enlightenments about the license files: I can't understand how the provided LGPL text can extend the completely different GPL one.
Regarding the GPL: http://www.gnu.org/licenses/gpl-howto.html "If you are releasing your program under the LGPL, you should also include the text version of the LGPL, usually in a file called COPYING.LESSER. Please note that, since the LGPL is a set of additional permissions on top of the GPL, it's important to include both licenses so users have all the materials they need to understand their rights." The real reason behind including the autotools is future-compatibility with patches. For example, if I opt to backport a fix from the master branch of SSSD that requires a makefile or configure check update, I'll need to run autoreconf for it to work properly. If you want, I can add this in explicitly in advance. I just usually don't bother to have it run autoreconf on any build without patches.
On further reflection, I think you're right. I can add the dependencies later if and when it becomes necessary. New Spec: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils.spec New SRPM: http://sgallagh.fedorapeople.org/packagereview/ding-libs/libpath_utils-0.2.1-4.fc13.src.rpm Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2414172
New Package SCM Request ======================= Package Name: libpath_utils Short Description: File-system path utilities Owners: sgallagh Branches: f13 f14 InitialCC: dpal
thanks a lot for these enlightenments, i understand better why you include also the GPL. :)
Git done (by process-git-requests).
Withdrawing this package. Upstream has changed packaging and it will be bundled into ding-libs. See https://bugzilla.redhat.com/show_bug.cgi?id=636947