textrender.t failing to load YAML::XS on SL6 about caf

[stdweird]

YAML::XS is provides by perl-YAML-LibYAML
but it seems the rpm deps are completely missing. i'll make sure this gets fixed.

there will be more dependencies that are now required to complete the tests.

[jouvin]

It was my guess but the version in EPEL SL6 doesn't seem to provide YAML::XS? Have you checked?

[stdweird]

http://dl.fedoraproject.org/pub/epel/6/x86_64/perl-YAML-LibYAML-0.38-4.el6.x86_64.rpm seems to have it

[stdweird]

as a general question: do we want explicit dependecies on the possibilities of TextRender?
currently support for e.g. tiny is sort-of dynamic, in that CAF::TextRender will try to load the dependency module (check for $self->load_module('Config::Tiny').
but we could make it mandatory so one is sure that tiny will work (e.g. with a general use Config::Tiny, nothing dynamic at all). this will then trigger the dependency in the rpm (i have no clue wrt solaris @ned21 does the solaris packaging translates a use X statement in a perl(X) dep like rpmbuild does?).

adding the depency in the pom.xml fixes the dependency on some perl modules, but then we might as well switch to the use X instead of the dynamic load_module(X).

[jouvin]

Clearly, you are right: this is not very good to define a static dependency if the dependency is in fact optional, based on the actual configuration...

[piojo-zz]

We have always enforced these dependencies in the metaconfig RPM. The reason was that most profiles will require multiple modules (f.i, Template::Toolkit, Config::Tiny and YAML::XS), and discovering that a valid profile fails when executing the component is fustrating, and difficult to troubleshoot.

[stdweird]

@Piojo so we require the dependecies and get rid of the load_module? or we leave the depencies in e.g. metaconfig pom.xml? (and any other piece of software that needs specific modules, has to add the deps themself?). i'm in favour of the second (it's clean, CAF dependencies stay minimal), although developers should be aware of this.

but i'm against this behaviour for the tests. the tests should test all functionality, so no missing modules are allowed for that imho.

[jouvin]

Dependencies and tests are in fact 2 different things as you generally don't install the RPM to test things... But probably we should pay attention to have explicit error messages about missing modules when failing tests (I think it was basically the case in this case, not sure in other components). I tried to had any test dependency I discover in rpms/quattor-development.pan in the OS templates.

I tend to share the opinion of @Piojo that we should avoid to have a valid profile leading to an error because of a missing dependency. So probably we should ensure that required RPMs for supported CAF::TextRender format are listed as a dependency (despite it will had quite a few RPMS not necessarily needed, not a problem as long as they are in the OS or EPEL) and a clear message if it happens that something is used and that there is a missing RPM.

[stdweird]

so what is the conclusion: we move the dependencies here via the pom.xml, but leave the code with the dynamic load_module? (eg on solaris, the pom dependencies have no effect since they are rpm specific).

[jrha]

If there is a potential for the code to be called, then these should be explicit dependencies.

[ned21]

I am a little bit conflicted on this one. I agree that a valid profile should ideally never "fail" due to a missing RPM, but at the same time, additional RPM requirements can be a real pain to support across multiple OSes--how long do we plan to support SL5 for? At MS we will have to support RH5 for several more years.

In this case I think the extra formats are sufficiently useful, and the number of rpms sufficiently small, that it's worth making them part of the dependencies.

[jouvin]

@ned21 : we have not discussed EL5 support timeline but I can't imagine we drop the support before it is end of life, i.e. end of 2017 if I'm right... So certainly a good number of years...

[piojo-zz]

When I wrote load_module, I thought metaconfig would be used for just a small amount of files, and hence it didn't make sense to bloat the system or the runtime with more modules, "just in case".

This seems to have changed now: most profiles use most modules, sometimes a lot. In that case, declaring statically the dependencies (with use statements) looks like the most maintainable solution in the long term.

[stdweird]

i propose then to do the following:

• for the current supported formats we add the dependencies via use
• we keep the load_module code in case people want to add more external modules that generate formats, without having to increase the bloat of CAF (or e.g. in case we don't agree it's good to add it because it breaks support for some OS). but in that case it will be up to the developers who use this functionality to make sure the dependencies are satisfied.

[stdweird]

i modified #67, please review