On 2007-06-27T16:28:48, David Lee <[EMAIL PROTECTED]> wrote: > > We've fixed this in hg.linux-ha.org/dev; it'll now additionally search > > the path for the command if required. > Does that fix happen to be Dejan's "e898fa7b59d3"?
No, I take the blame for it - http://hg.linux-ha.org/dev/rev/50c73d57f1f9 ;-) The changeset above is just a branch merge. > Technically, it may work. But I think it is the wrong place for > correcting this flaw. Possibly. > Which brings me on to ... > > Actually, I think we have a deeper problem in the build system, both with > a lack of consistency in handling such paths, and in many cases I think > deviating from the spirit of autoconf. > > This may be getting too technical for the general "linux-ha" list, so I'm > Cc:ing to "linux-ha-dev", which might be a more appropriate place to > follow this up. > > > In autoconf, we widely use "AC_PATH_PROGS(variable,prog-to-check-for)". > That's good. Example: > AC_PATH_PROGS(PYTHON, python) > > If the "prog-..." is found, variable is set to the full pathname, > otherwise it is not set. That's good and clean. Yes. > BUT ... we often use the additional, optional "value-if-not-found", which > I think we should be cautious about for true portability. And then, > worse, we set that to the simple program name; remember that the whole > point of "AC_PATH_PROGS" is to set the variable to a full pathname. True to a point, but otherwise we end up needing to have _all_ programs which heartbeat might ever need to reference in the environment when building heartbeat - just for setting a path! That is very clearly extremly undesirable. The smaller the build requirements, the faster the packages can be built, and if the dependencies are shallow, the more parallelization can go on when a full distribution needs to be rebuild. It's the packagers duty to make sure that the paths are right - ie, that if the program is not found, the substituted path matches the eventually installed system. Possibly the the value-if-not-found should be fully qualified pathnames though, that makes sense. On to your suggestions answers - > I suggest we need to rationalise: > > 1. Wherever possible our autoconf should simply use the basic: > AC_PATH_PROGS(variable,prog-to-check-for) > If it is not found we leave it blank, and let other code handle the > result. Often that other code might be elsewhere in "configure", for > instance if the absence of "prog..." is likely to be a show-stopper for > all heartbeat installations. Otherwise it could be (for instance) > run-time handling of the absence (empty variable) in a shell script. But, how's that much different from setting it to the program name and finding out just in the installed shell script as well? > Example 2: The current "fsck" is: > AC_PATH_PROGS(FSCK, fsck, fsck) > I argue that this is clearly wrong: "fsck" is multi-platform so we > should use the simple form (without the final ", fsck" clause), and > we cannot second guess its location (Linux: /sbin Solaris: /usr/sbin). Again, see above. It is important that the build system environment is as small as possible and only contains what is needed to actually _build_ the package - fsck is never used during build, so it doesn't need to be present, and so a build system doesn't install it either. So, while you're correct that configure.in should have fully qualified pathnames, using the simple form requires a bloated build environment. > (In the original poster's problem, if "fsck" was present, then configure > should have found it (or there was something flawed with his build process > which needs addressing). Nooo, the build environment was perfect, it only included what was needed ;-) _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
