On 2005 Apr 26 , at 14.05, Rankin, SE (Stephen) wrote:
> Hadn't thought about that; yes the manifest should contain paths with
> the final installation location the user has chosen. For the binary
> RPMS
> the installation location will be fixed but it could change for the
> source RPMS as they can be relocated.
>
> I will have to think about it some more but initially I think it is OK
> if the prefix path gets put in the manifest always, and DESTDIR is
> ignored. I in this case it was the mix of the prefix and DESTDIR that
> caused the problem.
>
> DESTDIR I assume just effectively redirects the installation to another
> location but any processing commands used in the installation will
> still
> use prefix, i.e. commands that change paths in scripts etc.. This means
> that entries in the manifest should always get prefix paths.
The DESTDIR support in automake is pretty crude -- all it does is add
the value of $(DESTDIR) to the front of all installation locations.
Since DESTDIR is usually empty, this usually has no effect. Thus
scripts (for example) are always installed in the directory
$(DESTDIR)$(bindir), which is equivalent to $(bindir) in the default
case where DESTDIR is undefined. It's $(bindir) which includes
$(prefix).
This means that if you had a makefile where prefix=/star, then 'make
DESTDIR=/tmp/staging install' would install binaries in
/tmp/staging/star/bin, help in /tmp/staging/star/hlp and so on.
It's possible (and according to the automake docs permissable) to say
'make prefix=/blah install', and prefix will be overridden for that
installation, without affecting any value of prefix that was burned
into scripts and binaries at build time. Off the top of my head, one
of the reasons why this might be useful and safe is if you wanted to
say 'make prefix=/star-ix86 install', with the expectation that
/star->/star-ix86 at some point.
Thus DESTDIR is for installing things into temporary staging locations
and little else; you can do slightly more by overriding prefix at
installation time, but with the risk that the subsequent installation
location will be out of sync with any burned-in paths. That is,
there's rope to hang yourself with either way.
See you,
Norman
--
----------------------------------------------------------------------
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
|