[Bug 225659] Merge Review: cracklib

[bugzilla at redhat.com]

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 at math.uh.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tibbs at math.uh.edu




--- Comment #5 from Jason Tibbitts <tibbs at math.uh.edu>  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 at GLIBC_2.2.5
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.