Hi!
Tom Lane [2005-12-20 16:39 -0500]:
> Yeah, the chosen-at-random pathnames ;-).
It's not that random, these are the paths that the FHS and Debian
policy prescribe for this package's structure (multiple versions
installable in parallel). :)=20
> I quote from the comments for make_relative_path():
Thanks, that was enlightening.
> In short, you can set --prefix however you want, but you really can't
> tack random decoration between --prefix and /bin, /share and friends;
> else make_relative_path will be unable to figure out how to transform
> one to the other.
I see, that at least makes the reason for the failure plausible.
However, if --bindir etc. cannot be set, then maybe configure should
not offer these options? OTOH the only thing that actually breaks is
the horology test suite, everything else works just fine since files
shipped in a package are never relocated.
> We could doubtless improve make_relative_path to some extent, but the
> mess you have above seems impossible to deal with. How is a mere
> program supposed to deduce where things were moved to, given only
> knowledge of the actual location of --bindir? I see little if any
> pattern that would allow prediction of the corresponding --datadir,
> let alone --libexecdir or --includedir ...
Right, with make_relative_path's current approach that seems to be
impossible. However, in a test suite I had expected a semantics like
$DESTDIR, i. e. instead of mangling the path somewhere in the middle,
the test suite should just prepend the tmp_check path.
It seems that the needs of the upstream tarball handling and the needs
of packaging differ somewhat. But instead of hacking in the interiors
of path handling, I will rather try another easy workaround.
Thanks,
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org