Adam Byrtek wrote: > Just to be sure, we are not speaking about service/daemon here, rather > a cron-like recurring task. Is there any policy/convention/precedent > when it comes to registering such recurring tasks by ports?
I don't see much difference for a service/daemon and a recurring task. I don't think there is any convention. I would prefer not to have anything running on my machine which I did not start epxlicitly - whether it's a daemon or a cron-like task. >>> 2. Munin consists of two components: munin-node that listens on a port >>> and provides statistics and munin-server that polls every node every 5 >>> minutes. Both are distributed in a single source distribution. I'm >>> considering either creating two separate Portfiles (munin-server and >>> munin-node) or using variants but in this case I'm not sure what >>> variants to introduce. Any suggestions when it comes to this? >> As they are distributed in separate sources, it is much easier to create >> two ports. In this case, the long_description should recommend each other. > > Looks like I wasn't clear enough, by "both are distributed in a single > source distribution" I meant there is only one source archive for both > :) Ah, sorry. I read that as 'each are distributed in a single source distribution' :-) As far as I know it is common to start munin-server on one machine and others report to this using munin-node over the network. So there is definitely the need to be able to install munin-node only. So the port munin could be the node only, and munin +server additionally installs the server. This would be reasonable as the node gets installed more often than the server. If you do this by variants or by separate ports does not matter that much, as I think two ports would not have conflicting files. The only thing you should note when using two ports is to set dist_subdir to the same value in both ports. This way users do not need to download it twice. Rainer _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
