[smokeping-users] Embedded modules?

[Terje Bless]

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 
security fixes.

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 
upstream maintainer!


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
>/usr/{share,lib}/perl{,5}

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