Bug 814765

Summary: %makeinstall doesn't set ${htmldir}
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: rpmAssignee: Fedora Packaging Toolset Team <packaging-team>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: ffesti, jnovy, packaging-team, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-08 11:58:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David Woodhouse 2012-04-20 15:32:41 UTC
We don't seem to set DESTDIR when running 'make install'. Instead, the %makeinstall macro overrides a bunch of the standard directories that autoconf sets. 

With openconnect configured with
%configure --htmldir=%{_docdir}/%{name}-%{version}

...installation fails, because it ends up trying to install into the root instead of into $RPM_BUILD_ROOT. If we were using DESTDIR for installation, this would have worked fine... isn't that what DESTDIR is *for*?

I've worked around it by setting --htmldir='${datadir}/doc/%{name}-%{version}', so that $datadir is expanded by make at 'make install' time, and does pick up the value that's overridden by %makeinstall. But that doesn't seem right...

Comment 1 Panu Matilainen 2012-04-21 05:57:32 UTC
http://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_macro_should_not_be_used

All current Fedora versions support %make_install macro which does the "right thing":

%make_install %{__make} install DESTDIR=%{?buildroot}

Comment 2 Panu Matilainen 2012-05-08 11:58:28 UTC
WONTFIX, like noted %makeinstall is plain broken and only kept around for backwards compatibility, new packages shouldn't use it at all so there's little reason to "fix" it to work with newer auto*tools.