Bug 193559

Summary:	my_print_defaults needed in main mysql package
Product:	[Fedora] Fedora	Reporter:	Ville Skyttä <scop>
Component:	mysql	Assignee:	Tom Lane <tgl>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	byte, hhorak
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	5.0.27-1.fc5	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-11-28 02:28:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.