Hi, OK. Sounds reasonable. And there are better things to do. And nobody here wants to touch configure&co.
Cheers, Dejan On Tue, Apr 18, 2006 at 02:06:43PM -0600, Alan Robertson wrote: > Dejan Muhamedagic wrote: > >Hello, > > > >I had a most strange experience recently with Heartbeat on SLES9. > >On the machine where I'm building the heartbeat packages, I > >installed the orarun package which contains the following: > > > >$ rpm -qvl orarun | grep fuser > >lrwxrwxrwx 1 root root 10 Jun 6 2005 /sbin/fuser -> > >/bin/fuser > >lrwxrwxrwx 1 root root 10 Jun 6 2005 /usr/bin/fuser > >-> /bin/fuser > > > >Now, when building heartbeat packages, the configure script > >figured out that fuser is available in /usr/bin, whereas on > >a SLES9 installation without the orarun package it is in > >/bin. The effect was a very curious behaviour where Filesystem > >resources would become unmanaged on start because the Filesystem > >RA would always fail as it failed to find fuser. It was > >extremely tricky to figure out what was going on. > > > >The question is: Who's fault is it: orarun or the heartbeat > >configure? Should the heartbeat configure process rely on what it > >finds on the box where it was compiled? Perhaps it would be better > >to have a config created during package installation. Perhaps > >absolute paths are not really necessary for stuff which resides in > >/bin and /usr/bin. > > > >In any case, the observed behaviour was so awkward and definitely > >needs to be changed. > > > >What are your thoughts on the matter? > > Configure runs at compile time. > > It is sensitive to LOTS of things which might or might not be present in > the target machine - commands (like fuser) and especially libraries. > > The configure process tailors the build process to match the environment > on the machine you're building on. That's really it's main purpose. > > There are MANY places where commands can be - which may not be in any > obvious standard path. Setting a PATH is not as safe as using the full > pathname. As far as I know, what we're doing is standard practice for a > configure-based software package. > > The error is to configure on a machine which is substantially different > from your final machine. It's not particularly our fault, nor is it > particularly orarun's fault. This is a restriction of configure. Even > if we fixed this one occurance, there would be dozens and dozens of > other dependencies on the target machine being the same as the configure > machine. > > You can either blame it on the "configure architecture", or you can > blame it on yourself. Your choice. > > There are numerous workarounds - establish symlinks, build on the target > machines, remove the orarun package, etc. > > -- > Alan Robertson <[EMAIL PROTECTED]> > > "Openness is the foundation and preservative of friendship... Let me > claim from you at all times your undisguised opinions." - William > Wilberforce _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
