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=225659 Jason Tibbitts <tibbs@xxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tibbs@xxxxxxxxxxx --- Comment #5 from Jason Tibbitts <tibbs@xxxxxxxxxxx> 2009-01-14 21:18:31 EDT --- Hmm, nothing from Jef. I took a quick look, though, and while the spec looks very nice and clean, I do have a couple of comments. Were this a new package that hadn't existed for approximately forever, I would complain about these files: /usr/include/crack.h /usr/include/packer.h /usr/sbin/mkdict /usr/sbin/packer as being terribly generic. However, if the first package in wins then this beats everything by default, and there's obviously no point in changing it now. rpmlint does have a few complaints which can be essentially ignored: cracklib-devel.x86_64: W: no-documentation cracklib-dicts.x86_64: W: no-documentation cracklib-python.x86_64: W: no-documentation True but not problematic. cracklib-dicts.x86_64: E: only-non-binary-in-usr-lib This is true, but I don't really see a problem in what you're doing. Does anything absolutely require those symlinks to be there? If it didn't, you could conceivably make this subpackage noarch (once the buildsys support for that is finished). cracklib-dicts.x86_64: W: dangling-relative-symlink /usr/sbin/packer cracklib-packer cracklib-dicts.x86_64: W: dangling-relative-symlink /usr/sbin/mkdict cracklib-format These are fine; the dependencies ensure that the symlinks aren't dangling. cracklib.x86_64: W: shared-lib-calls-exit /usr/lib64/libcrack.so.2.8.0 exit@xxxxxxxxxxx This is kind of weird, and usually indicates a bug or thinko in the package, but isn't a packaging issue. It also complains about a couple of things which could do with fixing: cracklib-dicts.x86_64: W: summary-ended-with-dot The standard CrackLib dictionaries. Terribly minor, but perhaps worth fixing if you're in the spec. cracklib.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/cracklib-unpacker ['/usr/lib64'] cracklib.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/cracklib-packer ['/usr/lib64'] cracklib.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/cracklib-check ['/usr/lib64'] cracklib-python.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/python2.6/site-packages/_cracklibmodule.so ['/usr/lib64'] I don't know why these didn't turn up earlier. Maybe libtool2 actually makes things worse? In any case, the recommended hack of tweaking libtool didn't help, so I guess a call to chrpath is needed. If the latter were fixed, I'd have no qualms about approving this. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review