pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

More collectd plugins for pkgsrc



I'm not sure what's the best way to deal with this: discuss here, file 
one giant PR, file a bunch of individual PRs?

I have added some 25 collectd plugins to pkgsrc, involving changes to 
sysutils/collectd, new collectd-* packages, modifications to various 
existing packages (mostly adding buildlink3.mk files) and patches.

Background: The statistic collection deamon, collectd, is implemented as 
a scheduler running components coined plugins, but which are all part of 
the upstream collectd distribution.

Some fundamental plugins are part of the sysutils/collectd package, some 
with no or simple dependencies are options of sysutils/collectd, some 
with substantial dependencies are factored out into separate packages, 
mostly sysutils/collectd-*.

But some plugins are currently not part of sysutls/collectd (probably 
for having been added upstream later); for some there currently is no 
collectd-* package, either because the dependencies were not in pkgsrc 
back in the day or because no-one was interested in them.
I've now added everything that could be added without importing dependency 
packages.

I've also refactored some of the sysutils/collectd/Makefile.common 
infrastructure.

The patch to existing pakages is 1213 lines, touching 31 files.
The 15 new collectd-* packages consist of only two files each, total 
213 lines.

I now also have a detailed list which plugins are in pkgsrc and which are 
not, and why: inherently Linux-specific, Linux-only implementation, 
dependencies not (yet) in pkgsrc, dependencies in pkgsrc, but not bulding 
(for me). This list may be beneficial if either new plugins are added 
upstream (so you know what you may try to add) or to check, from time 
to time, if dependencies have been pkgsrc-ed in the meantime.
How to deal with this list?


Home | Main Index | Thread Index | Old Index