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