On Feb 15, 2013, at 11:55 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Feb 15, 2013, at 2:20 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
>> For Linux and *BSD, the developers/distributors largely have their own package collections, which include Wireshark.
>>
>> For OS X and Windows, the vendors may have App Stores, to which Wireshark would almost certainly not be admitted, but they don't have any equivalent to the package collections provided by Linux distributors and *BSD teams. For those OSes, we act as "independent software vendors", even though we don't charge for the application, and offer the software through our own Web site.
>>
>> There do exist *third-party* package collections for OS X, such as MacPorts - I don't know of any for Windows - but we don't use them. I think relying on an OS X package collection would be overkill, as somebody who only wants a packet analyzer for OS X shouldn't have to install some Unix-geek-oriented package manager.
>
> I'm not following you - I'm not talking about adding wireshark to MacPorts or yum, etc. (it's already available through them)
MacPorts and yum/apt/etc. aren't the same sort of thing, which is the point I'm making.
yum/apt/etc., and the *BSD ports/package collections involve package collections maintained by the supplier of the OS (in fact, I'm not sure whether any Linux distributions draw a distinction between packages that are "part of the OS" and packages that aren't). I suspect most "non-developer common users" get their software through those package collections. We leave it up to the vendors in question to build and supply binary Wireshark packages through those package collections; we do not provide them ourselves.
MacPorts is a *third-party* package collection for OS X. The closest OS X equivalent to the package collections in Linux distributions and *BSDs would be the App Store, but we're not eligible for the App Store (for starters, we need *elevated* privileges or need to install a StartupItem or launchd daemon that grants everybody packet-capture privileges). I suspect most "non-developer common users" know little if anything about MacPorts, so we provide binary packages ourselves.
> I'm talking about letting a non-developer common user update Wireshark within Wireshark. Like a "Help->Update Wireshark" menu thing popping up a dialog box, with settings for frequency of auto-checking, and for auto-retrieval, and auto-installing. (though for Linux the last one would not apply)
For Linux, if that menu is worth providing at all, that menu item should just ask whatever the particular desktop environment has for doing package updates to check whether the *vendor's package collection* has updates and, if so, allow the user to download it and install it, because that's how the binary package are distributed.
However, unless having apps, rather than the package manager app, provide an "update" item such as that *for apps that come through the package manager*, is a common occurrence, I wouldn't bother with that *at all*, as users are presumably used to getting $PACKAGE_MANAGER_APP occasionally pop up and say "updates are available; do you want to install them?"
For OS X, however, we don't leverage an existing mechanism, such as the App Store or MacPorts, to provide binary packages, so we would provide the update mechanism ourselves.
> And this would be disabled by default.
I would *NOT* disable it by default for OS X or Windows.
>
>>> Even for Linux, you could just have wireshark check for a new version and tell the user. (if they enable such auto-checking)
>>
>> What is the user to do when informed that a new version exists? There's no guarantee that "apt-get update wireshark" or "yum update" or Synaptics Package Manager or... will give you that new version. At least on some distributions, the package management software will check for new versions in its repository and will offer them to the user; would that not be sufficient?
>
> Yeah for Linux this idea might be overkill, but basically I just meant that Wireshark would notify you a new version is available. How you get that new version is between you and [name_your_package_management_system].
Why not make the notification be between you and the package management system?
