[smokeping-users] Embedded modules?

[Tobias Oetiker]

Terje,

> The embedded modules are problematic in terms of, say, a security update to
> SNMP_Session where patching the system version of the module will not catch
> Smokeping's embedded version.

You can be sure that I will be aware of any changes simon makes to
the module, requiering an update ...

> I also note there are differences between your versions and upstream which
> makes trying to work around this (by dropping the embedded versions in the
> RPM) a more risky proposition.
>
> Also, for a distribution packaging system like Fedora's (the policy parts as
> well as the purely technical bits), having these private versions is
> non-optimal for the reasons above and because of the namespace clashes.

there are no namespace clashed since the modules are intalled in
smokepings private space ... 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.

> I can work around it, probably by removing the embedded versions at RPM
> %install time, but it'll make for rather more grotty code than I'd hoped; and
> in light of the diff from upstream, it'll be quite a lot more packaging
> overhead than I'm entirely happy about.

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.

> Either dropping the embedded versions or moving them into the Smokeping::
> namespace would make this much easier here (with the former being the much
> preferred path).

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

/usr/lib/smokeping or /usr/share/smokeping

smokeping does not provide an API for programmers outside the
smokeping realm there is no sense whatsoever of integrating the
smokeping modules into /usr/lib/perl or similar. This will only
make it trickier for people who start tinkering with it and find
parts of it splashed all over their system ...

> You wouldn't happen to know off hand whether the differences from
> upstream for these two modules are significant? If I were to
> filter them out in the RPM and replace them with an RPM-level
> dependency on the upstream modules, would this impact Smokeping's
> use of these modules?

see above ...

> I just quickly checked diff to see whether there were any changes ? so I'm a
> bit fuzzy on the details ? but the one difference I do recall seemed to be a
> tweaked regex in the module guts which should not affect Smokeping's ability
> to use the upstream version of the module.
>
>
> 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'm inclined to filter the RPM ?Provides? so it'll list 'smokeping' (i.e. the
> program) and not any of the 'Smokeping::*' modules. That's the sane option if
> those modules are only used internally by Smokeping, but will probably not be
> sufficient if any external code has a 'use Smokeping::Foo'.
>
>
> > see http://sepp.oetiker.ch
>
> Ah, that explains it. Thanks.
>
> I'll have to patch this at RPM %install time, as Gentoo does for their Portage
> version of the Smokeping package, but that should be manageable (if slightly
> ugly).

:-)

cheers
tobi
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902