[lkml]   [2013]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk executable

* Christoph Hellwig <> wrote:

> On Mon, Aug 05, 2013 at 10:31:32AM +0200, Ingo Molnar wrote:
> > Nonsense, a distro, if it truly worried about this, could create two
> > packages already, there's no need to expose configuration options in
> > the binary name itself and burden users with the separation. I
> > sometimes switch the UI frontend of perf depending on the workflow and
> > the terminal, it would be highly annoying if the binary name was
> > changed to expose configuration options.
> Which means you'd have to use a different tool name or have incompatible
> packages, both of which aren't desirable.

You'd have alternative packages - i.e. the configuration and dependency
difference is exposed in the packaging space, not in the user interface,
command name space.

(and yes, gtk linking in 20+ libraries is suboptimal, hopefully that will
eventually be fixed by the GTK project. If a leaner project with similarly
good UI elements comes around we might switch to it - without having to
rename the binary yet again.)

I.e. put the burden on packagers for too high library dependency
complexity, not on end users. A fair deal by any count.

> > The thing is, you strongly objected to perf itself when we offered it
> > up for an upstream merge and I'm not surprised you still don't like
> > it.
> I strongly objected to adding it to the kernel tree, and I still stand
> to that opinion because it makes using perf much more painful than it
> needs to be. [...]

That's still a red herring - 'using' perf for 99% of the users is to
install the perf package or to type 'make install' ...

> [...] I never disliked perf itself and use it frequently now that I can
> bypass some of the pains by just using an older distro package.

If you have special needs you could lobby your distro for different
versions - or you could build it from source.

Your solution, to split the binary into two parts, just to expose a
configuration option you don't want to enable in certain uses, burdens the
regular user of perf.

> But I'd much rather get this back to technical discussions than personal
> attacks..

You never replied to the original counter-arguments, such as this one from

Or this one from Andrew:

so I assumed your (still arguably dishonest) objections are still valid
and still broad - and are reflected in this thread.

That's not a personal attack by any means - we met before and I actually
like you as a person, I just don't like your opinion here and I don't like
your occasionally dishonest discussion style: because it only focuses on
the narrow issue of packaging complexity and does not look at the bigger
picture such as health of development and end user ease of use.



 \ /
  Last update: 2013-08-05 11:21    [W:0.941 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site