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

Reply via email to