On Dec 12, 2013, at 13:23, Peter Danecek <[email protected]> wrote:
> 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. 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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
