Re: kernel-perf subpackage

[Arnaldo Carvalho de Melo]

Em Thu, Jun 24, 2010 at 09:44:50AM -0400, Adam Jackson escreveu:
>  On Tue, 2010-06-22 at 17:37 -0700, Roland McGrath wrote:
>  >  %package -n perf
>  >  Summary: Performance monitoring for the Linux kernel
>  >  Group: Development/System
>  >  License: GPLv2
>  > +%if %{with_perftool}
>  > +Requires: kernel-perf(%{_arch}) >= %{version}-%{release}
>  > +%endif
>  
>  Oughtn't this be:
>  
>  Requires: kernel-perf%{_isa} >= %{version}-%{release} 
The version-release part shouldn't be there, backward compatibility is a
goal, so one can use an arbitrary perf binary with an arbitrary kernel.

Features that are used in a perf binary, say, what is needed by 'perf
probe', when not present in a kernel, should just produce an error
message at runtime when people try to use 'perf probe'.

- Arnaldo

kernel-perf subpackage

[Adam Jackson]

On Thu, 2010-06-24 at 11:32 -0300, Arnaldo Carvalho de Melo wrote:
>  Em Thu, Jun 24, 2010 at 09:44:50AM -0400, Adam Jackson escreveu:
>  > On Tue, 2010-06-22 at 17:37 -0700, Roland McGrath wrote:
>  > >  %package -n perf
>  > >  Summary: Performance monitoring for the Linux kernel
>  > >  Group: Development/System
>  > >  License: GPLv2
>  > > +%if %{with_perftool}
>  > > +Requires: kernel-perf(%{_arch}) >= %{version}-%{release}
>  > > +%endif
>  > 
>  > Oughtn't this be:
>  > 
>  > Requires: kernel-perf%{_isa} >= %{version}-%{release}
>  
>  The version-release part shouldn't be there, backward compatibility is a
>  goal, so one can use an arbitrary perf binary with an arbitrary kernel. 
I was more commenting that %{_arch} is x86_64 but %{_isa} is (x86-64).
Only the latter sort are automatically generated by rpm.

- ajax

kernel-perf subpackage

[Roland McGrath]

>  The version-release part shouldn't be there, backward
> compatibility is a
>  goal, so one can use an arbitrary perf binary with an arbitrary kernel. 
If we believed that we wouldn't have the perf wrapper script at all.
That script is really all the perf package (not kernel-perf) exists
for.  My patch is not about changing that picture at all.  If Kyle
believes you that we can rely on that, we can punt the wrapper script
and kernel-perf and just install the real binary directly in the perf
package.

The requirement I added is really just for the thinking that the perf
wrapper script has to match up with the packaging convention of the
kernel-perf.  So if we change where the wrapper script looks then
we'd want a compatible kernel-perf subpackage.  It doesn't prevent
you from having other kernel-perf's installed too.


Thanks,
Roland