Bug 193559 - my_print_defaults needed in main mysql package
my_print_defaults needed in main mysql package
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-05-30 11:23 EDT by Ville Skyttä
Modified: 2013-07-02 23:09 EDT (History)
2 users (show)

See Also:
Fixed In Version: 5.0.27-1.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-27 21:28:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2006-05-30 11:23:03 EDT
mysqldumpslow, which is in the main mysql package, needs my_print_defaults to
work.  Unfortunately my_print_defaults is in the -server subpackage.  It would
be nice if my_print_defaults would be moved to the main package; I'd rather not
install a DB server just in order to examine the slow queries.
Comment 1 Tom Lane 2006-05-30 12:00:24 EDT
I suppose that dependency didn't exist when the packaging decisions were first made.

I'll see what I can do, but if my_print_defaults adds a lot of dependencies of its own, the move may have to 
be in the other direction :-(
Comment 2 Ville Skyttä 2006-05-30 12:12:51 EDT
Sorry about not mentioning it initially, but I already checked the dependencies
(ldd output only) and it looks to me like there would be no additional ones.
Comment 3 Tom Lane 2006-06-01 12:50:54 EDT
I looked at this again and am unsure what to do.  It seems to me that
mysqldumpslow is useless except on a server machine, and therefore it ought to
be moved to the -server package.  On the other hand, my_print_defaults appears
to be functionality that would be useful for scripts even in a client-only

I checked MySQL AB's own RPM specfile, and they too have got mysqldumpslow in
the client package and my_print_defaults in the server package, so they haven't
thought it through either :-(

I'm a bit hesitant to move my_print_defaults to the base package because of
bloat concerns; the executable is a megabyte at the moment.  (I think this is an
upstream bug caused by careless library inclusion, but I dunno if they intend to
fix it.)  So right now I'm leaning to the mysqldumpslow-to-the-server-package

Comments?  In particular, what's your use-case for running mysqldumpslow on a
client-only machine?
Comment 4 Ville Skyttä 2006-06-01 14:08:37 EDT
Use case: I'm not running anything that is not absolutely necessary on a
production database server, but rather copy the slow query log elsewhere for
examination.  Having to install the DB server package in that "elsewhere" solely
for this purpose is overkill.

Anyway, moving mysqldumpslow to the server package would be an improvement over
the current situation, but I'd personally be inclined to do it the other way around.
Comment 5 Tom Lane 2006-06-01 19:59:03 EDT
I find that argument unconvincing --- if you're doing server management work, it's not unreasonable to 
expect you to install the server RPM.  I think a considerably stronger argument could be made that 
my_print_defaults belongs in the base RPM on its own merits, ie, it'd be useful in other scripts besides this 
one.  But I'm not sure what to do.  I've filed an upstream bug at
to see if they have any opinions about it.
Comment 6 Tom Lane 2006-11-27 21:28:43 EST
Well, the upstream decision was to move mysqldumpslow to the server package, so that's what I've done.

Note You need to log in before you can comment on or make changes to this bug.