[GSoC] migration

Umesh Singla umeshksingla at macports.org
Wed Jun 21 16:09:29 UTC 2017

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

Thank you for the help,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170621/51d4a303/attachment.html>

More information about the macports-dev mailing list