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=621898 --- Comment #5 from Chen Lei <supercyper1@xxxxxxxxx> 2010-08-09 08:24:39 EDT --- (In reply to comment #4) > > Some suggestions: > > 1.Provides: wbxml2 = %{version}-%{release} is not useful since no rpm is > > actually depends wbxml2 explicitly. > > > But it does not breaks anything. More ever think about third-party > repositories. > In addition, pure theoretically, there is a direct dependency: > $ repoquery --requires wbxml2-devel | grep wbxml2 > libwbxml2.so.0 > wbxml2 = 0.9.2-16.fc12 > libwbxml2.so.0()(64bit) > wbxml2 = 0.9.2-16.fc12 > One could say if wbxml2-devel is installed, wbxml2 is installed too. However > who knows how much broken system can an user have. This is not true, rpm should not try to depend on any shlibs explicitly. See http://fedoraproject.org/wiki/PackageNamingGuidelines#Renaming.2Freplacing_existing_packages "For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there." > > 2. > > BuildRequires: cmake, expat-devel, perl > > > > Requires: libxml2-devel, pkgconfig > > > > rpmbuild will add pkgconfig as a dependency automatically[1], > What about EPEL-5? It's not supported currently, but I'd like to be prepared > for future possibilities. > > perl is on the exception list of Buildrequires[2] > > [2]http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions_2 > > > It's not listed. wbxml2 is actually provided by some 3rd repos for rhel5, it'll better not to introduce big update in rhel5. perl is a dependency to those exception. See http://kojipkgs.fedoraproject.org/packages/gzip/1.3.13/4.fc13/data/logs/i686/root.log for a complete exception list. > > 3. > > > > %build > > # Upstream does not support in-source-directory building > > SRCDIR="$PWD" > > %define builddir ../build > > rm -rf %{builddir} > > mkdir %{builddir} > > cd %{builddir} > > %cmake "$SRCDIR" > > make %{?_smp_mflags} > > > > -> > > > > %build > > mkdir -p %{_target_platform} > > pushd %{_target_platform} > > %{cmake} .. > > popd > > > > make %{?_smp_mflags} -C %{_target_platform} > > > Why popd and then make -C if one can do make without -C and then popd? Either way is OK, but using ways listed in guideline will keep our spec files more clearly > > 4. > > > > %files devel > > %defattr(-,root,root,-) > > %doc AUTHORS BUGS ChangeLog COPYING GNU-LGPL NEWS README References THANKS TODO > > > > You should not try to add duplicate docs to -devel, rpmlint warnings can be > > safely ignored. > > > Ok. I will remove them but COPYING and GNU-LGPL because it's new rule that > every package must deliver license copy if some exists in sources. This is incorrect, because -devel subpackage already depend on mainpackage(e.g. a package which has -libs and -devel subpackages, then you just need to add license Text to -libs subpackage, mainpackage and -devel subpackage don't need this text). See http://fedoraproject.org/wiki/Packaging/LicensingGuidelines Subpackage Licensing If a subpackage is dependent (either implicitly or explicitly) upon a base package (where a base package is defined as a resulting binary package from the same source RPM which contains the appropriate license texts as %doc), it is not necessary for that subpackage to also include those license texts as %doc. However, if a subpackage is independent of any base package (it does not require it, either implicitly or explicitly), it must include copies of any license texts (as present in the source) which are applicable to the files contained within the subpackage. -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review