I only use the scripts to slave all the dependent binaries to the main binary. If you only have one binary, it's just a single line. (I also script literally everything, even single-liners).
I don't know if there's any way to do something like that without update-alternatives or your tool having some built-in awareness of the package's dependencies, but that's not really possible for a tool designed to be able to handle literally any arbitrary, user-compiled/installed package. Otherwise you get the system package manager again.
The tool I remember would basically do the equivalent of:
for file in `find /opt/package_name/version/` ; do
NEW=`echo $file | sed -e "s/^\/opt\/package_name\/version\//"`
ln -s $file /usr/local/$NEW
done
Where the base files are installed in /opt/package_name/version/ and all of them are symlinked into /usr/local/ by default with the option of changing individual file links. This way you change the entire 'installed' version of a package without needing application-specific path modifiers. But you can still build applications against specific versioned directories (if you have an app which requires BerkeleyDB 4.1 which conflicts with 4.0, for example)
(You can automate that for a pre-existing package if it's got relocatable code, but hardly as reliable as building it from scratch for the versioned directory and changing symlinks in /usr/local)
I don't know if there's any way to do something like that without update-alternatives or your tool having some built-in awareness of the package's dependencies, but that's not really possible for a tool designed to be able to handle literally any arbitrary, user-compiled/installed package. Otherwise you get the system package manager again.