livechecking ...

[Ryan Schmidt]

On Dec 12, 2013, at 13:23, Peter Danecek <Peter.Danecek at bo.ingv.it> wrote:

> On Dec 12, 2013, at 19:17 , Jeremy Lavergne <jeremy at lavergne.gotdns.org> wrote:
> 
>> 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.
> 
> Okay, but then a `livecheck.type none` default might be the "cleaner" default, at least it would not produce all these errors. Anyway, I will update my ports ASAP.

I guess it was thought that a default livecheck that sometimes tells you an update is available and sometimes tells you something went wrong is better than a default livecheck that never tells you anything.


>>> (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>
> 
> I see the point with multiple messages from subports. On the other hand, something like: `port livecheck installed` would not necessary produce the expected result, at least for all the python subports, right? But, maybe this is not the desired use case.

Correct, that’s not the intended use case. livecheck is for port maintainers to discover if new versions of the ports they maintain are available.


>>> (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 agree, that this is probably not the most common situation. But I **really** would like to have livechecking for all the single components of the Globus Toolkit in place. It would make tracking updates a lot easier easiest and that is what livecheck is for, and I do not see another way to implement livechecking here.

livecheck was implemented with the expectation that for any piece of software, there will be a single stable url that will list the latest version number. So far this has generally worked out ok. If this software you’re talking about does not have such a page, you should ask its developers to create one; it’s in every user’s best interest to be able to go to a predictable url to find out if their software is outdated or not.