Dependency on developer tools

[Ryan Schmidt]

On Oct 23, 2009, at 16:56, Scott Haneda wrote:

> On Oct 23, 2009, at 1:21 PM, Ryan Schmidt wrote:
>
>> On Oct 23, 2009, at 15:17, Lee Azzarello wrote:
>>
>>> On Fri, Oct 23, 2009 at 4:11 PM, Ryan Schmidt wrote:
>>>
>>>> I also once suggested that MacPorts should send stats about what  
>>>> got installed up to our server so we can tell what ports are  
>>>> popular, and also what kinds of systems people are running them  
>>>> on. But this was seen as "phoning home" and an invasion of  
>>>> privacy. It could be an opt-in feature, but I thought this would  
>>>> make it less useful.
>>>
>>> How about a "popularity contest" port that a user can install  
>>> optionally to gather stats about installed architectures?
>>
>> That's funny. :) And I like it. It also solves the problem of how  
>> to ask the user if they want it. I was dreading adding  
>> interactivity to either the disk image installer or the selfupdate  
>> mechanism. Having it all encapsulated within a port is a great idea.
>
> I love this, for just how amazingly simple it would be to support  
> the backend of the data collection.  If no one minds, I would like  
> to open a ticket, or be pointed to one, that shows the data that  
> would be desirable to collect.
>
> I am thinking, OS version, architecture, MP version, and installed  
> ports along with their versions.  I suppose inactive ports may be  
> nice, but I am not sure, I have a lot hanging around from upgrades,  
> that I have just been too lazy to remove, so to me, those are just  
> noise.

Actually maybe just a setting in macports.conf is more appropriate.  
After all this feature will probably need to be closely integrated  
into MacPorts base. Assuming we do it this way, and if the user has  
enabled the setting in macports.conf, I would want MacPorts to submit  
information about installed ports automatically anytime it changes  
(port install, port uninstall).

There would have to be a unique MacPorts install ID assigned to each  
installation, so that we avoid duplicates being submitted. There would  
have to be accommodation for transmitting the whole list of installed  
ports, to initially seed the database, and to transmit just individual  
ports that have been installed or uninstalled, and to not lose track  
of changes made while the network is unavailable.

I would want to track the user's current Mac OS X, Xcode and MacPorts  
versions, and for each installed port, its epoch, version, revision,  
variants, build_arch, universal_archs. Of course, we don't currently  
track build_arch and universal_archs for each installed port, though  
we really need to.