Created attachment 168787 [details] Patch Smartmontools contain a device database (drivedb.h) which lists quirks such as non-standard smart attributes for specific drives. While new version of smartmontools is released ~once a year, the database is update much more frequently (~once a month). Smartmontools unclude an utility (update-smart-drivedb) to update the database, but it's not compatible with ports system, as database will be overwritten when port/package is reinstalled. So, I propose to move database into separate port, sysutils/smartmontools-drivedb, which will be updated independently and more frequently than smartmontools and provide an up to date drivedb.
Honestly, i dont see any needs for this change, so probably i wont support it. My arguments: 1. drivedb.h is updated frequently, sometime much more often then once a month. I don`t see any point to open PR for every drivedb update, sometime it takes a long (weeks or months) to get reaction on already opened PRs, etc. 2. It will multiply number of efforts and will give no benefits for the users at all. 3. If port is reinstalled - user can just update db again if needed. You can add notice about that in the port install message. However i dont think that its really needed - for most of the users there is no real need to update DB if it already contains his products. And if not - its just a single shell script to run, what could be easier.
(In reply to samm from comment #1) > 1. drivedb.h is updated frequently, sometime much more often then once a > month. I don`t see any point to open PR for every drivedb update, sometime > it takes a long (weeks or months) to get reaction on already opened PRs, etc. Actually it's maintainer job to update the port timely, without need for PRs. If you can handle it, you may take maintainership. If not, I can handle it. In either case, even if database updates are delayed by months, it's still much better than being delayed by a year. > 2. It will multiply number of efforts It will not. > and will give no benefits for the users at all. The benefits are apparent: fresh database out of box, and no need to manually run update script after each (re)installation. > 3. If port is reinstalled - user can just update db again if needed. You can > add notice about that in the port install message. However i dont think that > its really needed - for most of the users there is no real need to update DB > if it already contains his products. And if not - its just a single shell > script to run, what could be easier. Not runing the script, obviously. You don't quite understand what you are speaking of. User must run a script on _each_ machine after _each_ reinstallation, which is complicated already. Which is worse, he must remember to run it _each_ time. This is inacceptable as it is, not speaking that falling back to older database may remove support for SSD currently in use, which breaks SSD monitoring, which breaks SSD problem detection, which leads to unexpected data loss. Finally, we can't officially support running the script at all, because it breaks checksums is pkg database.
If you want to keep -drivedb port yourself - please do. I think it does not make a lot of sense, because every update will require: 1. Diff 2. Opening PR in the web interface 3. Wait for approval 4. Wait for pkg rebuild if user using pkg. As result - a lot of time for nothing, w/o any real benefit. About checksum of the package - we can mark drivedb as config file or to keep original package somewhere. Also it was working this way for years and i never heard any problems with that, only issue so far was broken update script because of the recenet sourceforge changes. This is already fixed in the svn and will be fixed with a new version of smartmontools. So once again - if you want to do a lot of regular and useless job - please do a -drivedb package and maintain it. I do not see any benefits from this step for the smartmontools users and i personally feel that you are trying to improve the things which are already good.
and btw, i dont see such practice for other packages, like clamav. They are using update from external servers, not subpackages.
(In reply to samm from comment #3) > If you want to keep -drivedb port yourself - please do. It won't work without changes in smartmontools port because smartmontools-drivedb will conflict with smartmontools. > I think it does not make a lot of sense, because every update will require: > > 1. Diff > 2. Opening PR in the web interface > 3. Wait for approval > 4. Wait for pkg rebuild if user using pkg. No, every update will require just a single commit from active maintainer. Even if it requires PR cycle, it's still much faster than waiting for next release and it works out of box. > As result - a lot of time for nothing, w/o any real benefit. As I've already explained, there is apparent benefit for all smartmontools users with new devices. The database has grown 7% since the release. > About checksum of the package - we can mark drivedb as config file or to > keep original package somewhere. If you mean something like @sample, it won't work as after smartmontools update database will remain on old version. > Also it was working this way for years and i never heard > any problems with that Now you do. I do need support for newer drives on bunch of machines, and I do need it to work out of box and be reliable (e.g. not break after each update and require manual actions).
Ok, lets do this way then - feel free to separate the packages if you are going to support -drivedb. If not - please better leave it as is.
The next problem is that changed file will have different checksum than recorder in pkg database so it will not be removed by 'pkg delete' and can cause warnings for 'pkg check'. Is it possible to install this file in to /var/db/<something> , remove it from plist and add periodic script to update this file weekly? It can be done like for GeoIP port (database should be updated by user)
(In reply to samm from comment #6) > Ok, lets do this way then - feel free to separate the packages if you are > going to support -drivedb. If not - please better leave it as is. Will do, thank you.
(In reply to Miroslav Lachman from comment #7) > The next problem is that changed file will have different checksum than > recorder in pkg database so it will not be removed by 'pkg delete' and can > cause warnings for 'pkg check'. > Is it possible to install this file in to /var/db/<something> , remove it > from plist and add periodic script to update this file weekly? > > It can be done like for GeoIP port (database should be updated by user) That is why I've proposed to move the database to separate port. Updating periodically is possible, but it's fragile and unsafe. At least in needs something like gpg signature validation to work reliably.
Just for info: The drivedb update script could now (r4299) be disabled by ./configure --without-update-smart-drivedb This also removes any references from man pages.
Given it some though, I'm not really interested in supporting this without maintainer's cooperation.