livechecking ...

Jeremy Lavergne jeremy at lavergne.gotdns.org
Thu Dec 12 10:17:00 PST 2013


Peter Danecek wrote:
>  From the Guide I understand that the "fallback default" is `freecode`. Is this what works for most ports  out of the box? Or have all these ports now an explicit livecheck section?
>
> I now started using something like the following and so far it works in most cases. The assumption here is, that newer versions will go into a similar download directory (page) as where the current version comes from.
>
> {{{
> livecheck.type      regex
> livecheck.url       [lindex ${master_sites} 0]
> livecheck.regex     ">${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}<"
> }}}
>
> Wouldn't it make sense to something similar into the default `livecheck` sequence?
>
> However, implementing it exactly this way has one problem. When mirrors (predefined site lists) are used in `master_sites` code above will fail. It would be necessary to expand to the list provided by "mirror_sites.tcl" first.

The default is basically for sites which never have an explicit 
livecheck. Maintainers should ensure their livechecks are correct, be it 
default or otherwise. You're probably correct in assuming this 
necessitates an explicit livecheck for new Portfiles.

> (2) livecheck only for main port
>
> This disables livechecking for subports and enables it only for the main port. I am wondering why this is useful. I usually just added livechecking at the end, observed no problems so far.

Most maintainers only need to know that the package was updated, not 
that every instance defined in the Portfile was updated. For example, 
reports based on `port livecheck maintainer:petr` would be littered with 
duplicate messages unless you disable livechecks in the extraneous subports.

This does assume your subports are simply the same software, rather than 
separate packages. ZendFramework uses subports that are distinct packages:
<http://trac.macports.org/browser/trunk/dports/www/ZendFramework/Portfile?rev=113073>

>
>
> (3) For the globus ports it would be very useful to have the possibility to check a set of URLs (actually 2) extract the pattern according to the regex, concat the results and evaluate for the version in the in the usual way. I am thinking of a specification of this kind (in analogy to licences):
>
> {{{
> livecheck.type      regex
> livecheck.url       { http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
>                        http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/  }
> livecheck.regex     ">${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}<"
>
> Would something like this be TOO difficult to implement?
> Where should I go and look to get some better idea?

This doesn't sound like a common use case... that being said, there 
probably is no harm in implementing livecheck.url as a list. You'll want 
to look in the trunk/base/src code for the livecheck code and the 
trunk/dports/_resources for some other uses of livecheck.

I'd also recommend parsing the version (to get 5.2 from 5.2.5) so you 
don't need to update the livecheck everytime there's a new version.


More information about the macports-dev mailing list