Re: naming for mon-related packages

[Joey Hess <joey@kitenet.net>]

Roderick Schertler wrote:
> The mon program is a system for monitoring hosts and services and the
> like, and letting you know when one of hem has a problem.  The daemon runs
> tests as separate programs.  Up until now all the external programs have
> been written in Perl or sh, so the whole package has been architecture
> all.
> 
> A new upstream version has a monitor program written in C, so it needs
> to be split into a new package.  It's easy to imagine that this will be
> happening more in the future, and that somebody might want to package
> 3rd party monitor programs.
> 
> mon also uses external programs as clients and for sending alerts.
> There are already 3rd party client programs which exist, and more are
> coming.
> 
> How do you think such packages should be named?  I'm thinking I should
> use mon-monitor-* for monitors, mon-client-* for clients, and mon-alert-*
> for alerting programs.  The initial monitor is for RPC services, so I'd
> call it mon-monitor-rpc.

Please consider first if you really want to split the package.

* Will the sources for the different packages come from differnet places?
* Will any users want to instal just one of the packages and not the rest?
* Would the package be too big if not split? (Since it's 72k, I doubt it.)

If the answer to all of the above is "no", then you don't have a good reason
to split the package. Just turn it into an acrihtecture dependnat package,
which will have some architecture independant scripts in it too. This is
common, after all.

Number of packages bloat is a bad, bad thing.

With that said, if you do split it or add 3rd party stuff in other packages,
the chozen names are a little long, and won't look good in dpkg -l.

-- 
see shy jo