[23888] trunk/base/src/port1.0/portlivecheck.tcl

Paul Guyot pguyot at kallisys.net
Thu Apr 12 06:05:39 PDT 2007

On Apr 12, 2007, at 8:54 PM, source_changes at macosforge.org wrote:

> Revision: 23888
>           http://trac.macosforge.org/projects/macports/changeset/23888
> Author:   eridius at macports.org
> Date:     2007-04-12 04:54:10 -0700 (Thu, 12 Apr 2007)
> Log Message:
> -----------
> Fix livecheck to check for master_sites properly.
> If a portfile isn't set up for livecheck and isn't a sourceforge/ 
> freshmeat project, default to none, not freshmeat (which would  
> cause a failure).
> Clean up some if checks to avoid unnecessary syntax


> Revision: 23889
>           http://trac.macosforge.org/projects/macports/changeset/23889
> Author:   eridius at macports.org
> Date:     2007-04-12 04:55:42 -0700 (Thu, 12 Apr 2007)
> Log Message:
> -----------
> Make the up-to-date message for livecheck be info, not debug

Hello Kevin,

As I understand it, in addition to fixing and cleaning the code, you  
changed the semantics of livecheck significantly (without modifying  
the documentation).
Previously, livecheck would:
- report an error if it didn't work
- default to freshmeat if nothing was set
- be silent if the port was up to date

Now, livecheck will:
- report an error if it didn't work
- be silent if nothing was set
- report if the port was up to date

The old observed behavior when everything was ok (nothing was  
displayed) now means that nothing was checked, which is quite a  
problem if the goal of a maintainer is to keep their ports up to  
date. The advantage of the original semantics is that it drives port  
maintainers to write livecheck for their ports, while setting a good  
default so that most ports don't need a specific livecheck.  
Basically, you livecheck your ports and any output means that you  
have to do something, shall it implement a specific livecheck because  
default doesn't work or update because the port was updated upstream.

What argument do you have in favor of this change of semantics? Can  
we decide on reverting to the previous behavior?


More information about the macports-dev mailing list