livechecking ...
Peter Danecek
Peter.Danecek at bo.ingv.it
Thu Dec 12 12:35:43 PST 2013
On Dec 12, 2013, at 20:06 , Jeremy Lavergne <jeremy at lavergne.gotdns.org> wrote:
>
>
> Peter Danecek wrote:
>> 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.
>
> To me, an end user certainly would not have a need to use livecheck.
>
> A maintainer would need to use livecheck, but on their ports regardless of currently installed. This is why my example used `maintainer:petr` versus `installed`.
Sounds reasonable. Will update my ports for this as well.
>>>> (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?
>
> This is effectively the existing livecheck procedure.
Not exactly!
But, effectively, the behaviour was changes, since I tested the last time. I discussed it already on the list, which probably let to this changes.
It is the last part which is different.
If pattern not found it now gives me:
Error: cannot check if globus-common was updated (regex didn't match)
This is for sure reasonable. But in this special case: if no update was provided, the port is fine and up to date. But of cause if I would mess up the regex, this be remain undetected, so the procedure above is probably not ideal.
> It sounds like the components for globus are updated independently yet stored in the same location. Is this correct?
Correct, components live their own live, but at certain intervals are released as a whole toolkit packages. Package managers (for example on Linux) install the independent components, and so will Macports (hopefully). We (Dennis provided most of these ports, I CC him) also provide only a subset of all available components, basically the client part.
Here the list to get you an idea:
{{{
[radegast-wifi:globus-macports/ports/globus-common] petr% port search globus
globus-callout @2.2_1 (net)
Globus Toolkit - Globus Callout Library
globus-clients @2.0_1 (net)
Globus Toolkit - client collection
globus-common @14.9 (net)
Globus Toolkit - Common Library
globus-core @8.9_1 (devel)
Globus Toolkit - Globus Core
globus-ftp-client @7.4_1 (net)
Globus Toolkit - GridFTP Client Library
globus-ftp-control @4.5 (net)
Globus Toolkit - GridFTP Control Library
globus-gass-copy @8.6_1 (net)
Globus Toolkit - Globus Gass Copy
globus-gass-server-ez @4.3_1 (net)
Globus Toolkit - Simple File Server Implementation using GASS Server API
globus-gass-transfer @7.2_1 (net)
Globus Toolkit - Globus Gass Transfer
globus-gram-client @12.4_1 (net)
Globus Toolkit - GRAM Client Library
globus-gram-client-tools @10.4_1 (net)
Globus Toolkit - Job Management Tools (globusrun)
globus-gram-protocol @11.3_1 (net)
Globus Toolkit - GRAM Protocol Library
globus-gsi-callback @4.4_1 (net)
Globus Toolkit - Globus GSI Callback Library
globus-gsi-cert-utils @8.3_1 (net)
Globus Toolkit - Globus GSI Cert Utils Library
globus-gsi-credential @5.3_1 (net)
Globus Toolkit - Globus GSI Credential Library
globus-gsi-openssl-error @2.1_1 (net)
Globus Toolkit - Globus OpenSSL Error Handling
globus-gsi-proxy-core @6.2_1 (net)
Globus Toolkit - Globus GSI Proxy Core Library
globus-gsi-proxy-ssl @4.1_1 (net)
Globus Toolkit - Globus GSI Proxy SSL Library
globus-gsi-sysconfig @5.3_1 (net)
Globus Toolkit - Globus GSI System Config Library
globus-gss-assist @8.7_1 (net)
Globus Toolkit - GSSAPI Assist library
globus-gssapi-error @4.1_1 (net)
Globus Toolkit - GSSAPI Error Library
globus-gssapi-gsi @10.7_1 (net)
Globus Toolkit - GSSAPI library
globus-io @9.4_1 (net)
Globus Toolkit - uniform I/O interface
globus-openssl-module @3.2_1 (net)
Globus Toolkit - Globus OpenSSL Module Wrapper
globus-proxy-utils @5.0_1 (net)
Globus Toolkit - Globus GSI Proxy Utility Programs
globus-rsl @9.1_1 (net)
Globus Toolkit - Resource Specification Language Library
globus-usage @3.1_1 (net)
Globus Toolkit - Usage statistics collector
globus-xio @3.3_2 (net)
Globus Toolkit - Globus XIO Framework
globus-xio-gsi-driver @2.3_1 (net)
Globus Toolkit - Globus XIO GSI Driver
globus-xio-popen-driver @2.3_1 (net)
Globus Toolkit - Globus XIO Pipe Open Driver
}}}
The component sources grouped by their Globus TK version and for some reason separated into different directories:
When released as part of the toolkit:
http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/
But updates go here:
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/
Here the more concrete example for component `globus_common`, first for the "up-to-date case", than for the "outdated" case. The second uses the precedent toolkit release and the component version used for this release.
- matching the packages directory finds the correct packages:
livecheck.type regex
livecheck.url http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/
livecheck.regex ">${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}<"
DEBUG: Port (livecheck) version is 14.10
DEBUG: Fetching http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/
DEBUG: The regex is ">globus_common-(\d+(\.\d+)+)\.tar.gz<"
DEBUG: The regex matched ">globus_common-14.10.tar.gz<", extracted "14.10"
globus-common seems to be up to date
- matching the "updates" does not find anything and produces an error:
DEBUG: Port (livecheck) version is 14.10
DEBUG: Fetching http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/
DEBUG: The regex is ">globus_common-(\d+(\.\d+)+)\.tar.gz<"
Error: cannot check if globus-common was updated (regex didn't match)
I this case the is no update, so the port would be up to date.
** Now let's see what happens if some components are updated.
- matching the packages directory finds it is up to date:
DEBUG: Port (livecheck) version is 14.9
DEBUG: Fetching http://www.globus.org/ftppub/gt5/5.2/5.2.4/packages/src/
DEBUG: The regex is ">globus_common-(\d+(\.\d+)+)\.tar.gz<"
DEBUG: The regex matched ">globus_common-14.9.tar.gz<", extracted "14.9"
globus-common seems to be up to date
- but there is actually a update available:
DEBUG: Port (livecheck) version is 14.9
DEBUG: Fetching http://www.globus.org/ftppub/gt5/5.2/5.2.4/updates/src/
DEBUG: The regex is ">globus_common-(\d+(\.\d+)+)\.tar.gz<"
DEBUG: The regex matched ">globus_common-14.7.tar.gz<", extracted "14.7"
DEBUG: The regex matched ">globus_common-14.8.tar.gz<", extracted "14.8"
DEBUG: The regex matched ">globus_common-14.10.tar.gz<", extracted "14.10"
globus-common seems to have been updated (port version: 14.9, new version: 14.10)
> If so, I start to wonder if the various components are able to be installed independently such that you'd be using subports for them. At that point, each one can have its own livecheck using the same URL.
I guess, I do not understand this. But maybe I explained the situation already above.
We do not want to install the Globus toolkit as a single port. The components will be in separated ports, because it would be a very messy Portfile for something like 20-30 ports and probably quite some patching. So I would prefer to introduce a portgroup to hold all the repeated patterns and use single port for each component.
Anyway, if you interested in more details, you could browse the repo of Dennis or my fork on GitHub:
https://github.com/dvandok/globus-macports/tree/macports
https://github.com/dvandok/globus-macports/tree/macports
I have some newer (WIP) stuff not yet pushed.
Thanks for all the support!
~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/fb62e260/attachment-0001.p7s>
More information about the macports-dev
mailing list