Description of problem: I would suggest putting the zif library into a separate subpackage, for packaging cleanliness. The library is all that PackageKit-zif really needs. Plus, this would allow installing only the library by default, not the command-line executable, which is not really intended for end users. The following files from %files probably belong to the main package: %{_bindir}/zif %{_mandir}/man1/*.1.gz %config %{_sysconfdir}/bash_completion.d/*-completion.bash (COPYING is not needed here because the main package would require the library package, which would contain it.) The following files from %files probably belong to the library package: %doc README AUTHORS NEWS COPYING %{_libdir}/*libzif*.so.* %dir %{_sysconfdir}/zif %config %{_sysconfdir}/zif/zif.conf Version-Release number of selected component (if applicable): zif-0.2.3-1.fc17 How reproducible: Always Steps to Reproduce: 1. Install PackageKit-zif. Actual results: The zif command line executable, including man page and bash completion, is needlessly dragged in. Expected results: Only the zif library is dragged in.
Sure, makes sense. I'll do this for the next release.
Actually, would a -tools package be better? zif is really a library first, and a command line tool second.
Makes sense.
Something like this? diff --git a/contrib/zif.spec.in b/contrib/zif.spec.in index a7343ef..9f0a13f 100644 --- a/contrib/zif.spec.in +++ b/contrib/zif.spec.in @@ -30,6 +30,14 @@ access to the rpm database and the Fedora metadata for PackageKit. Zif is not designed as a replacement to yum, nor to be used by end users. +%package tools +Summary: Command line tools for using libzif +Requires: %{name} = %{version}-%{release} + +%description tools +This provides the zif command line tool that can be used as an +alternative to yum. It is not normally required. + %package devel Summary: GLib Libraries and headers for zif Requires: %{name} = %{version}-%{release} @@ -65,14 +73,16 @@ rm -f $RPM_BUILD_ROOT%{_libdir}/libzif*.la %files -f Zif.lang %defattr(-,root,root,-) %doc README AUTHORS NEWS COPYING -%{_bindir}/zif %{_libdir}/*libzif*.so.* -%{_mandir}/man1/*.1.gz %dir %{_sysconfdir}/zif -%config %{_sysconfdir}/bash_completion.d/*-completion.bash %config(noreplace) %{_sysconfdir}/zif/zif.conf %{_libdir}/girepository-1.0/*.typelib +%files tools +%{_bindir}/zif +%config %{_sysconfdir}/bash_completion.d/*-completion.bash +%{_mandir}/man1/*.1.gz + %files devel %defattr(-,root,root,-) %{_libdir}/libzif*.so
Yes, this looks like what I had in mind.
Cool, thanks. If you see anything else fishy then let me know. commit b371b4f292c69000b5586f8730834c63f2c2c5f3 Author: Richard Hughes <richard> Date: Sat Sep 17 12:35:46 2011 +0100 Put the zif command line tool into a subpackage in the example spec file Resolves https://bugzilla.redhat.com/show_bug.cgi?id=739283 I'll sync the spec file in two weeks time for the next release.
Splitting package to zif (with zif application) and zif-libs (with libzif) will be more close to widely used splitting packages method. Look for example dbus or xz or other packages: http://pkgs.fedoraproject.org/gitweb/?p=dbus.git;a=blob_plain;f=dbus.spec http://pkgs.fedoraproject.org/gitweb/?p=xz.git;a=blob_plain;f=xz.spec
So what derision will be about using common splitting method?
(In reply to comment #8) > So what derision will be about using common splitting method? I've added a -tools package in the new Fedora 16.
If zif (with only libzif) will be installed as dependecy of PackageKit-zif and someone will try to install zif application with "yum install zif" then answer will be that zif already installed but zif application still will be not installed - this may be confusing. But if package will be split in zif and zif-libs then will be no such problem.