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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
