On 2012-12-12 21:07, Ryan Schmidt wrote: > On Dec 12, 2012, at 12:01, Rainer Müller wrote: > >>> Something wrong... deleting and then appending the same dependency? >> >> Hm, right. This is the code that was originally written by Clemens, so >> probably he can clarify this. I guess it is written this way to avoid >> adding a dependency twice. > > Oh I see, because the port has a metric ton of variants and some of them add > the same dependency. > > For that matter: is the apache variant correct? It says it adds "Apache httpd > statistics" but it adds a dependency only on the curl port.
That's correct, this plugin is parsing the status page generated by mod_status. It does not link to apache itself and only needs curl to make HTTP requests. https://collectd.org/wiki/index.php/Plugin:Apache > My inclination would be to not worry about duplicate dependencies. They > shouldn't cause trouble. Er, except I see that "port lint" does check for > them, as it should. Well, when using depends_lib-append only, the dependency is added multiple times and the output in 'port info collectd' looks like this: Library Dependencies: curl, libxml2, libgcrypt, curl, libxml2, curl, curl, libmemcached, rrdtool, rrdtool, curl Somehow the duplicates do not look right to me... > If feeling pedantic, one could do e.g.: > > if {[variant_isset rrdtool] || [variant_isset rrdcached]} { > depends_lib-append port:rrdtool > } I try to use the [variant_isset] style only when a specific order of actions is required. I think it is usually better to have everything at a single place in the variant block. >> Although there is a valid point: should we check for duplicates in base >> when using depends_*-append? Are there other options we treat as a set >> rather than a string or list? > > We could filter out duplicates in base. On the other hand, that (and the > mechanism already employed by collectd) could interfere with another idea I > had, which was that base should warn if you try to -delete something (from > depends_lib or configure.args or build.env or any other option) that's not > there; I thought this might help to catch errors early. I have a feeling this > type of check might be too complicated for "port lint" to be able to do. For the check for deprecated/renamed options in 'port lint', I added an option_proc that counts the number of accesses to the deprecated option. This check is always in place and is evaluated every time the Portfile is parsed, but the results are only presented in 'port lint'. A similar mechanism could be used for checking -delete statements that do not actually delete any items. This -delete check would only interfere with the way of handling dependencies in the collectd Portfile in its current form. But if duplicates would be resolved by -append in base, I don't see any problem with such an additional check for 'port lint'. Rainer _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
