Hi Josh,
Taking a step back for a moment, why is an SQL database the best way to
> store this data? What sorts of queries are you going to want to run on it?
> Would a text (Tcl array) representation similar to the PortIndex be a
> better fit?
>
We need to store all the information about the existing state of the ports
first, then uninstall all the ports and re-install on the updated OS after
self-updating using the info we have in the database. So, we can't have a
temporary kind of Tcl array representation.
I can get this info from `port -v installed` and `port -v installed
>> requested` command, that is, calling /action_installed/ [1] which in turn,
>> calls /registry::installed/ [2] for each port from /snapshot_main/. Is this
>> best way to go?
>>
>
> Using registry::installed will work, but it's not the most efficient since
> it provides the same interface as the old flat-file registry (See below).
>
> Further, can you point me to some port action where it deals with
>> retrieving and populating tables as a hint? The /action_target/ used for
>> most of the port commands like /install/, /clean/, /fetch/ doesn't really
>> hint on how to deal with it.
>>
>
> These don't deal with SQL directly, they use the registry API.
>
> I hunted down till I reached /macports::registry.format/ -->
>> /receipt_{flat/sqlite}.tcl /files//which have a bunch of functions using
>> /registry::entry/ which I think is the most "basic" operation and then,
>> also /receipt_sqlite:://create_entry_l/function.
>>
>
> The way to get the list of installed ports is with 'registry::entry
> imaged'. Have a look at how reclaim.tcl does it for example.
>
Yes, thanks for this. @Brad, 'registry::entry imaged' or 'registry::entry
installed', may be?
I found 2 functions reg_entry_imaged() and reg_entry_installed() in
registry, which look almost similar implementation wise. Can you tell me
what is an imaged port? I mean, how will the two results be different?
The create_entry_l procedure is there to help in converting the old
> flat-file format to sqlite. It's probably not very relevant for you.
>
Yeah, ignoring this.
> If you do end up adding new tables to the db, you will need to add support
> for them to the entire stack from cregistry up.
>
I think you're referring to the work in last two commits here
<https://github.com/macports/macports-base/commits/gsoc17-migrate?author=umeshksingla>
.
Thank you for the help,
Umesh
