FWIW firefox has update checker - and linux packagers explicitly
disable it..
BTW: Just to reword Jed's statement - its not 'library' thats doing
the check - but the petsc makefile [ via 'chkopts' target] at
example/application compile time.
BTW: Presumably your patch is the following:
Satish
------
$ git diff |cat
diff --git a/conf/rules b/conf/rules
index f4b12c8..fe98ece 100644
--- a/conf/rules
+++ b/conf/rules
@@ -62,7 +62,7 @@ chklib_dir: chk_makej
# 3. Check if the shared libs are out of date
-chkopts: chk_upgrade
+chkopts:
@for LIBNAME in ${SHLIBS}; do \
library=${INSTALL_LIB_DIR}/$$LIBNAME.a; \
sharedlibrary=${INSTALL_LIB_DIR}/$$LIBNAME.${SL_LINKER_SUFFIX}; \
On Tue, 11 Nov 2014, Aron Ahmadia wrote:
> FWIW, I'm introducing a patch in the PETSc distribution in HashStack to
> disable this check from the Makefiles. I see the value of this being an
> opt-in check the user can run: `make info; make self-update`, but not an
> automated check unless the user opts-in at configure. That's the
> responsibility of the system/package manager, not a library.
>
> A
>
> On Tue, Nov 11, 2014 at 11:21 PM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
>
> > Hi,
> >
> > There is a difference between a library and an end-user application.
> >> Having "updaters" for end-user applications seems to be the status quo
> >> on Windows and to a lesser extent on Macs, but is resented on Linux.
> >> Having a library do these checks is not okay anywhere.
> >>
> >
> > I remember a session at the Google Summer of Code where some guy from one
> > of the open source wikis shared his experiences with having embedded a
> > 'counter pixel' in a release. In short, his lesson learned was that any
> > kind of "phoning home" is an absolute no-go unless made *very* clear to the
> > users (plus opt-out). This was pre-Snowden, so many people are now much
> > more sensible with respect to these matters...
> >
> > Best regards,
> > Karli
> >
> >
>
