Code review comment for lp:~jontai/openvista-gtm-integration/bug358242

> In scripts/etc/init.d/openvista we have
> 119 elif function_exists "log_daemon_msg"; then
> 120 log_progress_msg "$instance"
> 121 run_hook "$instance" ZSTART || end_msg=1
>
> Shouldn't line 120 be
> 120 log_progress_msg "Running startup hooks for $instance"

No. The way it works on Debian/Ubuntu is that you print the "main" thing first, then you print additional sub-components as you do them.

The example that the Debian Policy Manual gives in Section 9.4 is

     echo -n "Starting remote file system services:"
     echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
     echo -n " mountd"; start-stop-daemon --start --quiet mountd
     echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
     echo "."

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.4

We're not using echo directly, but it's the same idea.

> In other places, it appears the messages are different depending on whether
> log_daemon_msg is available or not. Not a big deal, but it might be nice to
> have them be the same.

Again, this is because it's a little different in each of the distros.

> In fact, it might be good to make one function for the
> scripts that does output and do the switching there, if such a thing is
> possible.

I considered this, but it's not just the textual message that is different, but the structure of when to log is different, too. I don't know how to encapsulate that cleanly in a function.

> Notes on building debs that seem "off":
> 1) Had to copy the GTM source to /tmp/ubuntu manually. It's not obvious that
> it has to be there.
> 2) Had an old gtm install in /opt/gtm that I had to ln -s /opt/gtm /tmp/gtm. I
> guess there's no way around that, though.
> 3) Had to add a group "gtm" just to build. That seems excessive.

Yea, these are known issues. Building the RPMs are just as painful. This is mainly because I haven't yet figured out how to install GT.M in a chroot -- I have to install it to the real, final, destination, otherwise the .o files have the wrong path to the corresponding .m files embedded in them.

The next step is to somehow clean up the package building process. For now, I'm happy enough with getting packages that are built from source that cleanly install and uninstall.

> Everything eventually did build and install.

OK that's good. I'm going to merge this.