Bug 989946: what plugins are we running?

Alec Leamas leamas.alec at gmail.com
Tue Jul 30 13:05:22 UTC 2013


Seems that this bug [1], 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 
bug)
- 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 
or not.

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

--alec


[1] https://bugzilla.redhat.com/show_bug.cgi?id=989946


More information about the devel mailing list