Daniel Kreling <krel...@linux.vnet.ibm.com> writes: > This patch enables iprutils supportconfig plugin for SLES when the user > specifies ./configure --enable-supportconfig. Autotools will send iprsos > script > to /usr/lib/supporconfig/plugins and when one issues the supportconfig > command, > the script will generate a report containing the plugin-iprsos.txt file. > If one wants the iprsos be sent to another directory, s/he must specify it > with > --enable-supportconfig=<path>. > --- > Including some changes suggested by Gabriel, not including the symlink to > iprsos, as we will enable either sosreport or supportconfig. Also, we are > still > to verify if SuSE keeps a separate repository for the supportconfig plugins. > We > can later remove it from our package if so. Thanks.
Thanks for following through with this. I really like your suggestion of enabling only one of them, but this is not currently implemented in this patch. In this proposed change, you are generating both versions and forcing packagers to remove the one they won't use. Not ok. I have another suggestion. Since we always want to build this and the only difference is where packagers are going to install it, why don't we drop this changes to Autotools all together and let SUSE packagers move it to the correct directory, iff they want to support it as a plugin? Obviously, our spec file in the git tree should move it to the plugin directory, since we (upstream) believe it should be a plugin in SUSE distros. This way, it would work nice with my last patch set, that focus on reducing the amount of steps packagers have to do to support iprutils in their distros. So, I propose only applying the patch that actually modifies the script, and them you could prepare a patch to update specfile with something like this, in the install section: %if 0{?suse_version} %{__mv} %{buildroot}/usr/sbin/iprsos /usr/lib/supporconfig/plugins/iprsos %endif What do you think? -- Gabriel Krisman Bertazi ------------------------------------------------------------------------------ _______________________________________________ Iprdd-devel mailing list Iprdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iprdd-devel