On Dec 12, 2013, at 19:17 , Jeremy Lavergne <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
