On Saturday 08 November 2008, Adeodato Simó wrote: > In my opinion, you should just invoke the configure script with the > paths of all programs as they are found in Debian, eg.: > > % ./configure --with-tar=/bin/tar --with-postgresql=/foo
After accepting the parameters it verifies their validity (program exists, perhaps the version, etc...) which will not work. > However, I have one question: why does the build process hard-code the > paths found in the build system? Why don't the scripts invoke the > programs without specifying a full path, as it is normally done in > scripts? With your way, people could not install a local version of tar > in eg. /usr/local/bin. There can be multiple versions of the same program. For example a non-gnu tar and a gnu-tar. Depending on a correct PATH variable will not be efficient and may be impossible to be worked with (imaginary: gnu-tar in /usr/local, non-gnu in /usr/bin, gnu-gzip in /usr/bin, non-gnu in /usr/local). The idea is that after detecting paths of the programs, they stay as-is. This also makes the scripts PATH independent. This helps with cron invocations, root-logins, su's, etc. It also reserves the possibility to use non-standard program locations like /usr/freeware/bin under IRIX where SGI-packaged GNU programs are stored. > > Also, how can I force vbackup to stay in unstable even after lenny is > > released when such bugs are found? (It makes the package mostly > > unusable). Is there a relevant how to? I've looked in maintainer's guide > > and in developer's reference but I didn't find anything related. > > Packages stay in unstable by default, unless somebody takes action to > remove them. Does that answer your question? I thought that after 10 days the're moved to testing, unless there is a reason not to do so. That's what I was referring to. p.s. Don't forget to CC me :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
