This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 1148195 - don't support %makeinstall
don't support %makeinstall
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-30 18:19 EDT by Rahul Sundaram
Modified: 2015-03-20 07:17 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-20 07:17:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2014-09-30 18:19:10 EDT
Description of problem:


Assuming %makeinstall is only supported in upstream RPM for legacy compatibility and noone should be using it, do consider patching out support for it in Fedora RPM just to avoid packages relying on it.
Comment 1 Panu Matilainen 2014-10-02 03:41:01 EDT
There are well over hundred package specs using %makeinstall in Fedora alone, never mind the larger ecosystem. Who's going to review the usage (remember there are cases where %makeinstall "works" where the more correct versions dont) and "fix" what clearly appears to work for these packages?

Rpm has no way of deprecating macros so its really hard to get rid of something once its in :-/
Comment 2 Rahul Sundaram 2014-10-02 04:00:44 EDT
I understand why from a upstream perspective, you might want to retain it even though it is broken but if a small patch is added to Fedora rpm (only rawhide branch) to drop the macro along with an announcement in fedora devel list long before the next rebuild, packages are bound to get updated to to use make_install or whatever is needed to stop using the macro.  A few days back, I corrected yet another spec file posted in fedora forum using the older macro and this could help.  Please consider.  

Thanks!
Comment 3 Rahul Sundaram 2014-10-02 04:04:18 EDT
Just in case you aren't aware.  Fedora packaging guidelines clearly say %makeinstall shouldn't be used anyway. So any packages using it is a clear violation of this guideline.

https://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_macro_should_not_be_used
Comment 4 Panu Matilainen 2014-10-02 04:25:56 EDT
Read more carefully, Fedora guidelines say:

Fedora's RPM includes a %makeinstall macro but it must NOT be used when make install DESTDIR=%{buildroot} works.

Its use is only prohibited when the more correct version works. So in those 100+ packages using it, some are likely violating the guidelines but it doesn't mean all of them are.

In the meanwhile, missing a more sophisticated deprecation method, this would be just as likely to get the message across...

--- a/macros.in
+++ b/macros.in
@@ -882,6 +882,7 @@ package or when debugging this package.\
 # Former make install analogue, kept for compatibility and for old/broken
 #  packages that don't support DESTDIR properly.
 %makeinstall \
+  echo "warning: %%makeinstall is deprecated, try %%make_install instead" 1>&2\
   %{__make} \\\
        prefix=%{?buildroot:%{buildroot}}%{_prefix} \\\
        exec_prefix=%{?buildroot:%{buildroot}}%{_exec_prefix} \\\
Comment 5 Rahul Sundaram 2014-10-02 04:28:38 EDT
Agreed.  FWIW, when I come across spec files during rebuilds or whatever, I never been able to find a good reason to use it.  

Would you mind pushing that change in?  Thanks
Comment 6 Jaroslav Reznik 2015-03-03 11:20:17 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 7 Florian Festi 2015-03-20 07:17:53 EDT
Added upstream as 0fddb3cbd80fc763ecacfea5b82631f7693915c2

Note You need to log in before you can comment on or make changes to this bug.