[petsc-dev] I hate nagupgrade

Satish Balay balay at mcs.anl.gov
Tue Nov 11 13:27:20 CST 2014


On Tue, 11 Nov 2014, Sean Farley wrote:

> 
> Matthew Knepley writes:
> 
> > On Tue, Nov 11, 2014 at 3:55 AM, Jed Brown <jed at jedbrown.org> wrote:
> >
> >> KAUST (or KSA?) internet can be flaky at times and my "make" was
> >> (silently) hanging indefinitely while trying to connect to mcs.anl.gov.
> >> Manually touching .nagged allows my build to proceed.  The hang could be
> >> fixed by adding a reasonable timeout, but I can't find a timeout in
> >> urllib.  Aron suggests that I try curl because all built-in Python url
> >> libraries are terrible, but I don't think we can depend on curl being
> >> installed, so we'd have to fall back to something.  We could implement a
> >> timeout using threads, if threads weren't broken on some architectures.
> >>
> >> Meanwhile, the professor next to me runs Little Snitch on his Mac and
> >> wants to know why PETSc's build is trying to connect to Argonne's
> >> servers.  His first thought was that it was a there for surveillance.
> >>
> >
> > I find it hard to believe he is a science professor with that kind of
> > inference
> > from the data (you can see it retrieves a webpage). Maybe climate ;)
> >
> >
> >> PETSc has a significant number of users that work behind firewalls or
> >> are otherwise sensitive to outgoing connections.  Although nagupgrade
> >> helps people stay updated and reduces some support email, I think it is
> >> unprofessional and a failure mode that I'd rather avoid.
> >>
> >
> > urllib2 has the timeout argument, so we should switch. I am not sure I see
> > retrieving a webpage as unprofessional. Is there a better way to update
> > information, or do we want a model that is completely dead once downloaded?
> > I think people now assume that this is not true.
> 
> Speaking from my experience as being a package maintainer, all of 0
> packages do this 'phone home' in MacPorts. That's a sample size of
> almost 20,000 packages.
> 
> One of the first things we package managers would do in this case would
> be to remove this "feature," since, as Jed mentions, there are many
> valid reasons to not have a connection to mcs.anl.gov (privacy
> concerns?). It is most definitely unrealistic to have this kind of
> behavior in production.
> 
> In general, I would love PETSc to "fall in line" more with a package
> manager layout but that's a different thread :-)
> 
> Just my two cents, of course.


2 options:

- remove petscnagupgrade
- or make it more explicit. i.e change <in example/user makefiles>:

ex1: ex1.o  chkopts

to

ex1: ex1.o  chkopts check_latest_version_on_petsc_server

Satish







More information about the petsc-dev mailing list