Predict vs Debian
Hi John!
Among many other things, I'm a Debian GNU/Linux developer. I saw your note
about Predict 2.0.0 on amsat-bb, and pulled it down with the intention of
whipping out a package for Debian.
Unfortunately, your build/install process is pretty hostile to the process
of packaging Predict for a distribution. I suspect you were trying to make it
easy for folks who don't understand much about Linux or compiling software,
but in the process you've made it very hard to package. I'd like to help fix
that, if you're willing. Here are a few of my initial thoughts:
- Modifying hard-coding paths in a .c file during the build process
is unusual. Typically, this would be done by programmatically
generating a .h file, which would then be included by the .c. This
is *much* cleaner, particularly if you're using a revision control
system to work on the sources.
- Hard-coding the path to the compilation directory in the executables
is pretty evil, and stuffing symlinks into the /usr/local tree
pointing to the build directory is unconventional at best. It's
flatly illegal for a Debian package to touch /usr/local, and the FHS
requires that files in a package conform to "normal" filesystem
layout conventions. One solution would be for the executable to
read and parse a config file at invocation that specified where to
find things like the keps and vocalizer executable. An equally
reasonable approach that would be much more amenable to packaging
than what you do now would be to define the paths as constants in
either the .c or a .h file.
- compiling in the presence or absence of sound support is less
wonderful than allowing that to be configured at runtime. It looks
like it would be easy to make the use of vocalizer a variable read
from a config file if you did a config file, or a command-line
option in either case.
- when run without superuser privs, the install program silently
claimed to have installed the program, but didn't create any links
since it didn't have permission to scribble in /usr/local/bin. It
appears that you aren't ever checking the result codes from your
calls to symlink() in installer.c...
If you want to preserve the notion of a cute installation tool that helps the
user configure, compile, and install the program, that's fine. If things are
structured correctly, I ought to be able to ignore that tool and compile the
programs and structure the files to build a Debian package.
I suspect that a mild restructuring to make the program both easy for folks
to handle on random systems, and easy for someone like me to package for
inclusion in a distribution, would be pretty easy. If you want to tackle this,
I'd be pleased to consult. If not, I'll spend an evening "fixing it" so that
I can package it for Debian... and you'll be welcome to the resulting diffs
if you want to incorporate them for your next release.
Let me know what you think. It's exciting to have another GPL'ed hunk of ham
software, and I'd love to see it in the hamradio section of Debian. If I can
help make that happen, let me know...
Bdale, N3EUA
Reply to: