Bug 193559 - my_print_defaults needed in main mysql package
Summary: my_print_defaults needed in main mysql package
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-30 15:23 UTC by Ville Skyttä
Modified: 2013-07-03 03:09 UTC (History)
2 users (show)

Fixed In Version: 5.0.27-1.fc5
Clone Of:
Environment:
Last Closed: 2006-11-28 02:28:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ville Skyttä 2006-05-30 15:23:03 UTC
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 16:00:24 UTC
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 16:12:51 UTC
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 16:50:54 UTC
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
installation.

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
answer.

Comments?  In particular, what's your use-case for running mysqldumpslow on a
client-only machine?

Comment 4 Ville Skyttä 2006-06-01 18:08:37 UTC
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 23:59:03 UTC
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
http://bugs.mysql.com/bug.php?id=20216
to see if they have any opinions about it.

Comment 6 Tom Lane 2006-11-28 02:28:43 UTC
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.