[100449] users/raimue/ports/sysutils/collectd

Rainer Müller raimue at macports.org
Thu Dec 13 02:22:32 PST 2012

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.


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


More information about the macports-dev mailing list