Philippe Gerum wrote: > On Mon, 2006-12-11 at 01:16 +0100, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Sun, 2006-12-10 at 11:21 +0100, Jan Kiszka wrote: >>>> The only part of the Xenomai user-space package not yet following >>>> standard installation rules is the testsuite. It gets installed to >>>> $prefix/testsuite, by default /usr/testsuite. The attached patch is an >>>> approach to overcome this unusual layout. >>> Ack. Implementation-wise, we have to fix the following though: >>> >>> xeno-load.in needs to be fixed, so that passing a single dot as argument >>> correctly picks the default runinfo target in the current directory. >>> This currently does not work as expected. >> [obviously now fixed in svn] >> >>> The second patch works around a problem with sudo relying on the >>> contents of the user's PATH variable. This won't work for people using a >>> version of sudo compiled with the secure path option by their favourite >>> distro. In that case, /usr/xenomai/bin (or whatever the user picked to >>> install xenomai) won't appear in that secure path, so the binary program >>> given in the runinfo file won't be found. A possible option is to >>> provide a relative path to locate the binary program, >>> e.g. ../../../../bin/latency for the latency test, as the example patch >>> shows. Not pretty, but the other way would need to autoconfiscate the >>> runinfo files, or at least run them through sed before installing, so >>> that we could substitute some placeholder with $exec_prefix. >> Relative paths are not fully safe, > > Why, provided the sudo sub-shell in xeno-load changes dir to the > target_dir variable contents? >
Because exec_prefix (=>bindir) may be different from prefix (=>pkgdatadir), thus there is no fixed relation between the .runinfo location and the binaries until after the installation.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
