Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=868263 --- Comment #4 from Jan Synacek <jsynacek@xxxxxxxxxx> --- (In reply to comment #1) > Issues: > ======= > [!]: Development (unversioned) .so files in -devel subpackage, if present. > Note: Unversioned so-files directly in %_libdir. > See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages > ** These files should go to devel subpackage, e.g. > libguile-srfi-srfi-1-v-3.so Fixed. > Generic: > [x]: Package is licensed with an open-source compatible license and meets > other legal requirements as defined in the legal section of Packaging > Guidelines. > ** I guess there are mentioned many unneeded/compatible licenses in the > license tag, I think that LGPLv2+ should be enough for the resulting > package, as upstream claims in the LICENSE file. Fixed. The spec now only mentions LGPLv2+. > > [x]: Package requires other packages for directories it uses. > ** Maybe I would like more /usr/share/guile-1.8 than /usr/share/guile/1.8 TODO > [!]: Fully versioned dependency in subpackages, if present. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in %package > devel > ** We probably need the %{?_isa} if we support multilib Fixed. > > [x]: Package complies to the Packaging Guidelines > ** I would use more the mver macro to subst hardcoded macros Fixed where possible. > [x]: Package is named according to the Package Naming Guidelines. > ** The current name is probably not against guidelines > (http://fedoraproject.org/wiki/Packaging: > NamingGuidelines#Multiple_packages_with_the_same_base_name) , but other > compat packages doesn't use 'dot' delimiter for version, e.g. compat-guile18 > instead of compat-guile1.8 > ** In case you expect more compat versions to exist in parallel, you may > consider compat-db approach, e.g. base name without version and subpackage > for each compat version. Renamed to compat-guile18. > [!]: If the package is a rename of another package, proper Obsoletes and > Provides are present. > ** I think there should be obsoletes and provides. Fixed. Hopefully correctly. > [?]: Package does not own files or directories owned by other packages. > ** I need to see the guile-2 spec. Provided. > [!]: Package has no %clean section with rm -rf %{buildroot} (or > $RPM_BUILD_ROOT) > Note: %clean present but not required > ** No blocker, OK for EPEL Fixed. > [!]: Patches link to upstream bugs/comments/lists or are otherwise justified. > ** Compat package, probably OK OK. > [!]: SourceX / PatchY prefixed with %{name}. > Note: Patch1 (guile-1.8.7-multilib.patch) Source0 (guile-1.8.8.tar.gz) > Patch3 (guile-1.8.8-deplibs.patch) Patch2 (guile-1.8.7-testsuite.patch) > ** No blocker Not possible anyway. > [!]: Spec use %global instead of %define. > Note: %define mver 1.8 > ** Easy fix Fixed. > [!]: Large data in /usr/share should live in a noarch subpackage if package > is > arched. > Note: Arch-ed rpms have a total of 1986560 bytes in /usr/share 10240 > compat-guile1.8-devel-1.8.8-1.fc16.x86_64.rpm 1976320 compat- > guile1.8-1.8.8-1.fc16.x86_64.rpm > ** It's about 2MB of data that could probably go noarch, but no blocker Those are guile procedures written in Scheme. I don't think 2MB is that much, so I'm leaving this as it is. > Rpmlint > ------- > compat-guile1.8.x86_64: W: one-line-command-in-%post /sbin/ldconfig > ** this could be easily fixed Fixed. > /usr/lib64/libguile.so.17.4.0 linux-vdso.so.1 > ** you can try to re-link with --as-needed Done. Spec now exports LDFLAGS="-Wl,--as-needed". > Please provide the guile-2 spec to allow me to do more deep checks. Done. Spec URL: http://jsynacek.fedorapeople.org/compat-guile1.8/compat-guile1.8.spec SRPM URL: http://jsynacek.fedorapeople.org/compat-guile1.8/compat-guile1.8-1.8.8-2.fc19.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kkBAyFRVD8&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review