Bug 225068

Summary: Don't require %{_includedir}/bind if libbind is disabled
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: bindAssignee: Adam Tkac <atkac>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ovasik
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-02-01 14:14:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Scheck 2007-01-28 15:34:39 UTC
Description of problem:
Try to build the bind package with having libbind disabled, it will fail 
because %{_includedir}/bind doesn't exist.

Version-Release number of selected component (if applicable):
bind-9.3.3-5

How reproducible:
Everytime, see above.

Expected results:
Please apply the following patch or better:

--- snipp ---
--- bind.spec       2007-01-28 16:13:52.000000000 +0100
+++ bind.spec.rsc   2007-01-28 16:13:55.000000000 +0100
@@ -531,7 +531,6 @@
 %{_libdir}/liblwres.a
 %{_libdir}/*so
 %{_includedir}/bind9
-%{_includedir}/bind
 %{_includedir}/dns
 %{_includedir}/dst
 %{_includedir}/isc
--- snapp ---

Comment 1 Adam Tkac 2007-02-01 14:14:30 UTC
Remove %{_includedir}/bind isn't good solution. I put it into if-endif statement

Comment 2 Robert Scheck 2007-02-01 16:00:04 UTC
%{_includedir}/bind IS already conditional AND was unconditional. And I was just
proposing to remove the unconditional one...

Comment 3 Adam Tkac 2007-02-01 16:08:07 UTC
(In reply to comment #2)
> %{_includedir}/bind IS already conditional AND was unconditional. And I was just
> proposing to remove the unconditional one...

You have dead right. %{_includedir}/bind is twice in spec file now. I don't know
why I didn't see it before... Thanks for your information, I'm going to remove
it in next release.

Regards, Adam