[Bug 172869] Review Request: nss-mdns - glibc plugin for .local name resolution

bugzilla at redhat.com bugzilla at redhat.com
Fri Jun 22 05:48:17 UTC 2007

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: nss-mdns - glibc plugin for .local name resolution


tibbs at math.uh.edu changed:

           What    |Removed                     |Added
           Keywords|Reopened                    |
         AssignedTo|bnocera at redhat.com          |tibbs at math.uh.edu
               Flag|                            |fedora-review?

------- Additional Comments From tibbs at math.uh.edu  2007-06-22 01:48 EST -------
The files are being installed into /lib on x86_64 instead of /lib64.  The simple
fix is to simply pass "--libdir=/%{_lib}" instead of "--libdir=/lib".

I have no idea about the multilib issues; I suspect that this is simply a
situation where users who don't install both arches (as is currently yum's
default behavior) just get weird behavior.  Still, the issue isn't really
something that can be solved within the confines of this package, since the
x86_64 version can't require the i386 package nor can it actually contain i386

In any case, let's look at rpmlint output for the package after the above fix to
get it building on my build server.  I don't believe that any of these are blockers.

W: nss-mdns summary-not-capitalized glibc plugin for .local name resolution
  I personally think this is OK; I wouldn't normally capitalize glibc in any 

W: nss-mdns dangerous-command-in-%post perl
W: nss-mdns dangerous-command-in-%preun perl
  Dangerous, maybe.  Ugly, definitely.  But you've already described why this 
  needs to be done, and in lieu of /etc/nsswitch.d I don't think there's any 
  other option.

I note you're not using the %{?dist} tag.  There's certainly no requirement that
you do so, but I always ping folks to make sure they understand the issues that
crop up when you don't use it.

You need fine-grained dependencies; the package doesn't just require perl, it
needs it there to run its post script.  So you need:
   Requires(post): perl
   Requires(post): /sbin/ldconfig
You can also drop the Requires: perl bit, unless the package actually needs perl
in order to run normally.

* source files match upstream:
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* build root is OK.
X license field says "GPL" but the LICENSE file says "LGPL"
* license is open source-compatible.
* license text included in upstream source but not in the package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64) (after the above fix)
* package installs properly
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
X final provides and requires missing some dependencies; see above.
   nss-mdns = 0.10-1

* %check is not present; no test suite upstream.  I have no means at the moment 
  to test this package.
X shared libraries are present; ldconfig is called as necessary but dependency 
  on ldconfig in %post is not present.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
X scriptlets present are OK, but the dependencies are off.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the package-review mailing list