Seems that this bug , together with yesterday's libvoikko issue has
opened a can of worms. Since the discussion seems to be rather general,
it might make sense to continue here on the list.
Trying to summarize some aspects, the first is how we make the decision
what plugin(s) to run:
- If we base decisions on the sources, we should use buildsrc IMHO. We
should not care about things removed in %prep.
- Shouldn't the basic strategy be to check in what's in the rpms?
- How much should we handle pitfalls such as java packages putting
.class files into a .zip container?
- Could we assume that the GL are followed? Then we could just look
into %javadir and %jnidir to check if this is a java package...
Next aspect is user feedback on what plugins are run:
- Stan's approach is a short note why a certain plugin is activated (see
- Another way might be to focus on what plugins are run or not rather
then why.. Something like
Active plugins: generic, java
Disabled plugins: ruby, C/C++, R, perl, python, php
- In any case, we need better logs describing why plugins are activated
Finally, if we provide feedback like above it should be possible to
tweak the list of running plugins. Something like
--plugins/-P e. g., -P java:off,C/C++.
If a plugin is listed here the on/off value basically overrides the
automatic is_applicable() decision.
Just my 5 öre