rpms/poker-eval/FC-4 poker-eval.spec,1.8,1.9

[Paul Howarth]

On Mon, 2006-06-19 at 09:35 +0200, Thomas Vander Stichele wrote:
> Hi,
> 
> > > > Why the %makeinstall?  makeinstall is an anachronism and should only be
> > > > used if make DESTDIR=... install is nonfunctional.
> 
> I was asked to drop this as well from a .spec and just like Christopher
> I was unaware that %makeinstall was so strongly discouraged.
> 
> The explanation in the Packaging Guidelines is, IMO, a little poor in
> providing any reasoning for this, and could be expanded.  As it's
> explained right now it's not making the case it should be making.  I'll
> detail below, since most of the text from the wiki seems to come from
> this mail.
> 
> > >   What's wrong with using it?
> > %makeinstall overrides a set of environment variables during
> > "make install". I.e. it performs
> > make prefix="..." includedir="..." ...
> 
> They're make variables, not environment variables.  While the difference
> is subtle, there is a difference.  In any case, this is a statement of
> fact (albeit wrong), not a description of what is wrong with %
> makeinstall, afaict ?
> 
> > It is error prone,
> 
> This is too vague to mean anything.  make DESTDIR=... install is also
> error-prone.
> 
> >  can have effects inside of (broken) Makefiles
> 
> So can make DESTDIR=... install.  Consider a Makefile that *does not
> have* DESTDIR :)
> 
> >  and can
> > trigger rebuilds when executing "make install".
> 
> This could be true; in all these years, I've never noticed it happening
> though that I can remember, so it must be that the 5 seconds of
> additional install time did not really worry me on 5 minute package
> builds.
> 
> >  If a package contains
> > libtool archives, it will cause broken *.la's being installed.
> 
> We don't install .la files anyway, so this is a red herring.
> 
> > "make DESTDIR=... install" overrides a single environment variable
> 
> If "single" vs. "many" is the reason, then this is just as much an
> "aesthetic" reason, and I prefer Christopher's in that case.
> 
> >  and
> > is supposed to be specially designed for re-rooting installs to a
> > different installation root ($RPM_BUILD_ROOT) than the package has been
> > configured for ("/").
> 
> True, and I like DESTDIR as well when I need it.  This seems to me the
> only really valid reason to discourage %makeinstall, but as such it
> seems better to me to remove the "fake reasons" from above, and just
> explain this one better, with an example or something.

Actually the single best reason hasn't been included here. The variables
overridden by %makeinstall are sometimes used for things other than
locations to install files to. For instance, some libraries might use a
construct like:

echo $(libdir)/libraryname >
$(DESTDIR)$(sysconfdir)/ld.so.conf.d/libraryname.conf

to add their own library directory to the linker's search path. Using %
makeinstall in this case would result in the buildroot directory being
prepended to the directory name in libraryname.conf.

This is actually the same issue as for libtool, but libtool breakage is
only one of the possible problems.

> As it stands, the packaging guidelines on this topic sound more like
> unfounded dogma and thus are not very believable.

And they also should not say "MUST NOT" use %makeinstall; some Makefiles
don't support DESTDIR, and %makeinstall is indeed the right approach to
use for those packages (subject to them not breaking as described
above).

Paul.