[MacPorts] #61154: Error: port deactivate failed: this entry does not own the given file

[MacPorts]

#61154: Error: port deactivate failed: this entry does not own the given file
-------------------------+--------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  base        |    Version:  2.6.3
Resolution:              |   Keywords:
      Port:              |
-------------------------+--------------------

Comment (by ryandesign):

 To clarify, the power outage occurred while the worker was busy doing
 builds, possibly while it was modifying the registry.

 Looking in src/cregistry/entry.c, `reg_entry_deactivate` prints "this
 entry does not own the given file" whenever the SQL statement `UPDATE
 registry.files INDEXED BY file_actual SET active=0 WHERE actual_path=? AND
 id=?` does not change any rows. It appears to assume the only reason why a
 row is not changed is an ownership problem. But in this case, I wonder if
 the problem is really that the row was already changed before the power
 went out.

 Poking around in the registry with `sqlite3`, I see that most of gettext's
 files are marked as active, but some aren't.

 {{{
 sqlite> select * from ports where id=9837;
 9837|gettext|5f96e69dd9bdd69fcd8bbcc0e1b726ec1f4f302db28dd0b7a28ef6326418e34c-4461|/opt/local/var/macports/software/gettext/gettext-0.19.8.1_2.darwin_15.x86_64.tbz2|2|0.19.8.1|2|||installed|1595235473|image|x86_64|0|darwin|15|libc++|0
 sqlite> select count(*) from files where id=9837 and active=1;
 1772
 sqlite> select count(*) from files where id=9837 and active=0;
 158
 }}}

 I suppose a fix would be for me to mark those inactive files as active;
 then `port` should be able to deactivate it.

 My hope would be that MacPorts would perform sets of related database
 operations using transactions that either commit or rollback as a whole so
 that there is no possibility to leave the database in an inconsistent
 state. However, based on previous problems I've encountered and maybe this
 one as well, it's evident to me that MacPorts either is not doing that or
 is not doing it correctly.

-- 
Ticket URL: <https://trac.macports.org/ticket/61154#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS