The emerge message says that user needs to manually update drivedb.h but it's not clear whether a) and b) are steps to be done in order(ie. a AND then b) which is what I assumed at first glance, or that the user should choose to do only one of them (ie. a OR b)
Steps to Reproduce:
1. emerge =sys-apps/smartmontools-7.2
After emerging sys-apps/smartmontools-7.2 the following is shown:
* Messages for package sys-apps/smartmontools-7.2:
* Log file: /tmp/ebuild.logs/build/sys-apps/smartmontools-7.2:20210103-001414.log
* WARNING: There's already a drive database in '//var/db/smartmontools'!
* Because we cannot determine if this database is untouched
* or was modified by the user you have to manually update the
* drive database:
* a) Replace '//var/db/smartmontools/drivedb.h' by the database shipped with this
* release which can be found in '//usr/share/smartmontools/drivedb.h', i.e.
* cp "//usr/share/smartmontools/drivedb.h" "//var/db/smartmontools"
* b) Run the following command as root:
make it clear(in text form) that you have to do either a) OR b) but not both!
because both are overwriting file /usr/share/smartmontools/drivedb.h
From the above emerge message, it appears as if after drivedb.h is updated in step a), then step b) is needed too, due to the name of that script, as if some sort of binary database is then created from drivedb.h (but that is not the case). Therefore, user should be let known that only one of a) OR b) should be executed, but not both in order.
$ diff -u /usr/share/smartmontools/drivedb.h /var/db/smartmontools/drivedb.h && echo same
I guess, the ebuild could do this check too, prior to spamming the message.
Also »Because we cannot determine if this database is untouched«: If the file /var/db/smartmontools/drivedb.h is equal to previous version of /usr/share/smartmontools/drivedb.h (which could be saved) the ebuild could easily determine, whether the db was untouched.