livechecking ...

[Peter Danecek]

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.


>> (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.

>> (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.

Well, maybe there is another one: 
Only checking http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/. But then again, I would need to be able to influence how the fact that an update is NOT found is interpreted. 

The desired behaviour would be then:
search pattern
if pattern found: compare to the current version 
   if ${largest_pattern} > ${version}: is outdated
   if ${largest_pattern} == ${version}: is up-to-date
   if ${largest_pattern} < ${version}:  unexpected situation (maybe error)
if pattern not found: is up-to-date

But it is not possible to implement this kind of behaviour neither, right?

Which alternative is better, easier to implement?

> 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.

Agreed! 
These are determined automatically (it is partly implemented), but I would like to introduce a portgroup for this. Not sure on the details, I will follow up on this as well ;-)

Here, I just copied the whole URL, just in case someone would be interested to look it up.

~petr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1762 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20131212/e5b7ddc1/attachment.p7s>