usage numbers for macports vs. homebrew?

Ryan Schmidt ryandesign at macports.org
Tue Mar 18 14:43:38 PDT 2014


On Mar 18, 2014, at 16:35, Clemens Lang wrote:

>> * A careful review of what we emit, and when (we don’t clearly distinguish
>> when a port was loaded from a build-bot vs built by hand, unless you know
>> what to look for), etc.
> 
> Agreed. We should also remove some of the clean messages that might be unexpected (when the thing that really gets cleaned is the port loaded from the registry, i.e. when uninstalling).

I thought I had filed a ticket for that already but I can’t find it now. I also found it confusing that sometimes (on some of my systems, but not on others; I don’t know why) each port install results in four “Cleaning” messages.


>> * Spinning ANSI indicators during loading operations, etc, where we can. We
>> could do this in loading, activation, etc. The hardest time would likely be
>> in building and configuring, where we don’t have any hooks back from the
>> build.
> 
> What you probably haven't seen because most servers to HTTP/1.1: The progress bar actually comes in a progress indicator variant aswell that can be used for that. Activation is certainly on my todo list of things to display a progress bar for.

Good idea.

> For configure/build/etc I was thinking about writing simple parsers for the formats emitted by some build systems that give progress info (e.g., cmake, ninja).

Yes. I worried it might be confusing to have progress indicators for some builds but not others, due only (invisible to the user) to the particular build system being used. But your next idea could overcome that:

> We might even try to estimate progress using the number of lines printed and a web-based database of the number of lines generated during build/configure/destroot of a port. It might be erratic, but it would still give *some* indication of the duration of the build.

Also, consider the OS X startup progress bar, back when OS X had one: originally it was very accurate, but by Tiger it had been changed to just advance at a more or less constant rate regardless what was happening; the boot process frequently would complete before the progress bar had gotten to the end. Just some indication that something is happening is useful to the user, even if it’s not completely accurate.

muniversal builds can also be used to inform a progress bar.

> Also, we really need to work on the dependency calculation stuff to print a plan of action before starting and print progress information (building port x of y) while building.

That would be nice too.



More information about the macports-users mailing list