[GSoC] MacPorts Usage Statistics

Derek Ingrouville dergro at gmail.com
Tue Mar 29 20:50:41 PDT 2011


On 29 March 2011 20:28, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> I would find it useful to collect this info. We discussed it briefly some years ago and rejected it due to privacy concerns. Making it an opt-in model would resolve that concern, but make the data less useful. I had envisioned this information being available to our web site, which could then show things like popular ports this week, etc.
>

I think many people would find this information interesting and
useful. One aspect of this project could be server side code which
analyzes the data so that it can be easily made available on the web
site.

>
> What is the thought behind having this implemented as a port? Would the port install the actual program that gathers the statistics and sends them to a central MacPorts server? If so, would MacPorts base need to be modified to look for and call this program at certain times?
>

The thought behind having this as a port was simply that Debian does
it that way with popcon and I was using that as a model. The port
would install the program that does the collection. A cron task would
invoke the program and send the data to a MacPorts server. This of
course raises the question of which user should execute the program.

MacPorts base should not have to be modified in any way for this to
work. Please correct me if I'm wrong, but I believe it should be
sufficient to look in ${prefix}/var/macports/software to gather a list
of installed ports. This way the tool wouldn't have to share any code
with MacPorts base.

> I would have thought stats gathering would be an integral part of MacPorts base, implemented in MacPorts base, with new configuration options exposed in macports.conf for whether the user wants to participate, and perhaps, as you say, what specific information they want to disclose. But I have no idea how Debian's popcon works or why it's done that way.

My first impression was that since code for this task wouldn't be
directly related to managing ports then perhaps it was better located
outside of MacPorts base. One fairly large advantage of integrating
with MacPorts base is that users wouldn't have to install anything in
order to opt-in. They could, for example, run a port command which
enables information collection or simply edit macports.conf. If it
becomes necessary to look at receipts it would also be better to use
the API already provided by MacPorts.

That said, I have no hard preference either way and would find more
discussion on this issue helpful.


More information about the macports-dev mailing list