WTH — five minutes later, and now the new install is also doing the same issue, whereas it was not a bit ago.
This is very strange. K > On Apr 25, 2021, at 3:31 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > I went through the exact same process on a different Tiger machine, using the > /opt/bootstrap process with curl and sqlite3, and for whatever reason, this > other system does not show the same “sudo” issue with “port”. > > So — it must be something sporadic on that machine I guess… otherwise there > are no noted issues so I don’t know what, but it’s not consistent and > reproducible, so … I’ll just see what happens there. > > Ken > > > > > > > >> On Apr 25, 2021, at 9:57 AM, Ken Cunningham <ken.cunningham.web...@gmail.com >> <mailto:ken.cunningham.web...@gmail.com>> wrote: >> >> >> >>> On Apr 24, 2021, at 11:59 PM, Ryan Schmidt <ryandes...@macports.org >>> <mailto:ryandes...@macports.org>> wrote: >>> >>> >>> >>> On Apr 24, 2021, at 23:23, Ken Cunningham wrote: >>> >>>> On Apr 24, 2021, at 7:36 PM, Ryan Schmidt wrote: >>>> >>>>> Does only the first non-sudo `port` command fail? Does running the >>>>> command with `sudo` once allow it to work without `sudo` a second time? >>>>> >>>>> (There could be a one-time need to modify the registry sqlite database >>>>> for the new method.) >>>> >>>> Yes, indeed that seems to be the case. I just tried it again on that same >>>> system, and indeed I no longer need to use sudo for basic commands. Good >>>> catch. >>> >>> Ok, then this is probably just the way it is for now. I seem to recall a >>> similar situation happening with some previous MacPorts base update. >>> Whenever we change the structure of the registry in some way, we increase >>> the registry version and there is code (our update_db function) that knows >>> what SQL statements need to run to convert an old registry version into the >>> new one. This requires write access to the database. >>> >>> Maybe there is a way that we could postpone the sqlite update process until >>> you run a sudo port command. But depending on what the modifications are >>> that the update performs, a new MacPorts might not be able to understand >>> the structure of an old MacPorts registry until the sqlite update is >>> performed. >>> >> >> >> Well, now I am a bit confused. I restarted the Tiger machine, and the >> problem is back: >> >> $ uname -a >> Darwin MacMini.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 >> 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 >> >> $ which port >> /opt/local/bin/port >> >> $ port -v >> sqlite error: attempt to write a readonly database (1544) while executing >> query: ATTACH DATABASE '/opt/local/var/macports/registry/registry.db' AS >> registry >> while executing >> "registry::open $db_path" >> (procedure "mportinit" line 712) >> invoked from within >> "mportinit ui_options global_options global_variations" >> Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: >> attempt to write a readonly database (1544) while executing query: ATTACH >> DATABASE '/opt/local/var/macports/registry/registry.db' AS registry >> >> $ sudo port -v >> MacPorts 2.6.99 >> Entering shell mode... ("help" for help, "quit" to quit) >> [Users/cunningh] > quit >> Goodbye >> >> >> >> My apologies for not immediately understanding why it worked last night and >> not today. >> >> As Josh says, perhaps this is my own cross to bear due to how I build >> MacPorts. I will try it on another Tiger system I have, PPC. >> >> Ken >> >
