[smokeping-users] Embedded modules?
link at pobox.com
Fri Jun 8 10:07:58 CEST 2007
tobi at oetiker.ch (Tobias Oetiker) wrote:
>You can be sure that I will be aware of any changes simon makes to the
>module, requiering an update ...
Hmm. Unfortunately that doesn't really help the distribution
case — or my internal needs — as in both cases there is a
separate responsibility for tracking and providing relevant
Disregarding my internal process for now, but looking at the
Fedora case as an example; if a security issue in SNMP_Session
should come to light, the project would need to then add patches
for the main SNMP_Session package _and_ for the embedded version
in the Smokeping package. If you happened to be available and on
the ball, any given specific case might not need to issue such a
patch, but in general they'd need to take into account the
possibility that you will at some point want to take a vacation. :-)
This is why static linking or private versions of things like
zlib or graphics libraries are discouraged (strongly); no matter
how good each individual upstream maintainer is at updating for
security issues, in the aggregate — which is what the distro
sees — there will always be at least one upstream developer
who is unavailable or delayed, and closing the hole can't wait.
>there are no namespace clashed since the modules are intalled in
>smokepings private space
AFAICT, no matter where the .pm files happen to live in the
filesystem, SNMP_Session and Config::Grammar are still in the
global Perl namespace. If these really are private application
specific copies of what happens to also be forked from a general
upstream version, they, IMO, belong in the Smokeping:: namespace.
>... as I said, my prime objective is to have a stable system and I can only
>achieve this by keeping the core components close to my vest.
Hmm. Cricket, for one, also uses SNMP_Session and has had little
problem with its API stability.
In this specific case, one of the tasks of a RPM packager is to
track down any incompatibilities such as this and reflect them
in the RPM package's dependencies. If SNMP_Session released,
say, an API-incompatible version, the Smokeping RPM package
would have an explicitly dependency on the compatible version.
In my experience — and your's may of course differ — there
are more problems with changes in the Perl interpreter and core
modules itself than with SNMP_Session (I'm not familiar with Config::Grammar).
>>I can work around it, probably by removing the embedded versions at RPM
>>%install time […]
>you should not 'work' around it, since if smokeping breaks due to an
>incompatible update of either Config::Grammer or SNMP_Session people will
>come running to me and not to you.
Hmm. Well, given my main goal here is to deploy this package
internally — and I will likely end up being its main user —
I can assure you that particular load will be minimal! :-)
An additional intent is — since I'm doing the work anyway —
to package it up for submission to the Fedora and EPEL projects,
but those communities are usually quite good about reporting
packaging issues to the distribution. In fact, it's usually more
of a problem to get them to report upstream issues to the
However, if you're adamant that packagers should not “work
around” the embedded copies of those modules I'll take that
into account at least for what I submit to Fedora and EPEL (not
sure what I'll do internally). I suspect the package QA review
will bring up these very issues, but I'm not sufficiently
familiar with their policy to know whether these will be
considered significant issues or not. It may well be they'll
consider this a non-issue for all I know.
>I think the problem is that you are looking at smokeping as a 'perl'
>application. Look at it as 'smokeping'. This means that all the smokeping
>'program helper stuff' goes into [private dir]
Actually this same issue goes no matter the implementation
language; statically linking a library (zlib, say) or using an
embedded version (getopt, gettext, etc.) causes these kinds of
issues and is therefore strongly discouraged if not banned outright.
>>Oh, and if you (or anyone on the list) happen to know; do any external
>>code use any of the packages in the Smokeping:: namespace?
>not that I know of, but as I said it does not matter since this is not a
>perl module for external consumption ... it does not belong into
I was thinking along the lines of plugin modules or third-party
web interface to the config or something; stuff that's tightly
integrated but separately distributed. Typically such code would
be a separate RPM package with a dependancy on either
'smokeping' (the app) or the specific Smokeping::* module it
depended on, depending on the type of addon it was.
In any case, I take it there are no such beasts in the wild and
hence I do not need to provide any 'Provides' hooks to hang it
on for the Smokeping package?
“Temper Temper! Mr. Dre? Mr. NWA? Mr. AK, comin´
straight outta Compton and y'all better make
way?” -- eminem
More information about the smokeping-users