Bug 241389

Summary:	smartd-conf.py pulls in a big dependency chain
Product:	[Fedora] Fedora	Reporter:	Ville Skyttä <ville.skytta>
Component:	smartmontools	Assignee:	Tomas Smetana <tsmetana>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-06-21 13:34:38 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ä 2007-05-25 16:25:32 UTC

On my trimmed down FC6 box:

# yum install smartmontools
[...]
Installing:
 smartmontools           i386       1:5.37-1.1.fc6   updates           302 k
Installing for dependencies:
 cryptsetup-luks         i386       1.0.3-2.1        core              598 k
 dbus                    i386       1.0.1-12.fc6     updates           470 k
 dbus-glib               i386       0.70-6.fc6       updates           152 k
 dbus-python             i386       0.70-6           core              161 k
 hal                     i386       0.5.8.1-6.fc6    updates           368 k
 hwdata                  noarch     0.191-1          core              254 k
 libvolume_id            i386       095-17.fc6       updates            37 k
 libxml2-python          i386       2.6.28-1.fc6     updates           710 k
 pciutils                i386       2.2.3-4          core               82 k
 pm-utils                i386       0.19-3           core               42 k

I don't need smartd-conf.py for anything, thus I don't appreciate 10 packages
which includes 2 daemons that get enabled by default being pulled in to satisfy
its dependencies.  Some ideas how to improve this:

1) Put smartd-conf.py in a subpackage which is installed by default but can be
removed, change init script to run it only if it's available.

2) Leave it in the main package, but drop the dependencies and adjust the init
script to treat failures running smartd-conf.py as non-fatal and emit a
descriptive message.

Comment 1 Tomas Smetana 2007-06-20 12:00:28 UTC

I don't know much what to do with this one, frankly. The script was introduced
to ensure the smartmontools get configured and user won't have to do any manual
changes. Both the proposed solutions allow the smartmontools to remain
unconfigured. This is exactly what we don't want to happen.

Comment 2 Ville Skyttä 2007-06-20 15:44:22 UTC

I don't see how giving users the chance to opt out from the autoconfig would be
a bad thing.  Approach 1) would implement that pretty trivially, and if the
subpackage (let's say smartmontools-autoconfig) is installed by default in the
installer, people who want it or don't mind it would just not touch it and end
up having it installed and doing its thing.

By the way, doesn't smartd's DEVICESCAN functionality work adequately?

Comment 3 Tomas Smetana 2007-06-21 13:34:38 UTC

You're right. I have split the package and put the script in smartmontools-config.