Red Hat Bugzilla – Bug 241389
smartd-conf.py pulls in a big dependency chain
Last modified: 2007-11-30 17:12:05 EST
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.
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.
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?
You're right. I have split the package and put the script in smartmontools-config.