Bug 208398 - sysutils/smartmontools: split drive database into separate port
Summary: sysutils/smartmontools: split drive database into separate port
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Dmitry Marakasov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-30 14:26 UTC by Dmitry Marakasov
Modified: 2016-05-24 21:12 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (samm)


Attachments
Patch (4.00 KB, patch)
2016-03-30 14:26 UTC, Dmitry Marakasov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov freebsd_committer freebsd_triage 2016-03-30 14:26:37 UTC
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.
Comment 1 Oleksii Samorukov freebsd_committer freebsd_triage 2016-03-30 14:35:22 UTC
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.
Comment 2 Dmitry Marakasov freebsd_committer freebsd_triage 2016-03-30 16:30:46 UTC
(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.
Comment 3 Oleksii Samorukov freebsd_committer freebsd_triage 2016-03-30 16:37:49 UTC
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.
Comment 4 Oleksii Samorukov freebsd_committer freebsd_triage 2016-03-30 16:42:06 UTC
and btw, i dont see such practice for other packages, like clamav. They are using update from external servers, not subpackages.
Comment 5 Dmitry Marakasov freebsd_committer freebsd_triage 2016-03-30 17:03:13 UTC
(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).
Comment 6 Oleksii Samorukov freebsd_committer freebsd_triage 2016-03-30 17:09:23 UTC
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.
Comment 7 Miroslav Lachman 2016-03-31 10:51:57 UTC
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)
Comment 8 Dmitry Marakasov freebsd_committer freebsd_triage 2016-04-06 17:30:42 UTC
(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.
Comment 9 Dmitry Marakasov freebsd_committer freebsd_triage 2016-04-06 17:32:19 UTC
(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.
Comment 10 Christian Franke 2016-04-16 20:05:07 UTC
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.
Comment 11 Dmitry Marakasov freebsd_committer freebsd_triage 2016-05-24 21:12:20 UTC
Given it some though, I'm not really interested in supporting this without maintainer's cooperation.