Migrate app data on upgrade

C. Florian Ebeling febeling at macports.org
Tue Mar 24 02:11:25 PDT 2009


On Tue, Mar 24, 2009 at 2:54 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Mar 23, 2009, at 16:04, C. Florian Ebeling wrote:
>
>> Is there a working example of migrating app data to a new format in a
>> some port? There are obviously a number of issues with doing something
>> like this:
>>
>> - finding the source format version from a portfile with higher version
>> - finding app data from a range of versions in possibly a number of
>> locations
>> - working with a number of formats from a higher version portfile,
>> and previous (creating) versions possibly uninstalled
>> - probably many others
>>
>> Are there good paths to follow? Is it worth doing? Is having
>> version-specific (default) data directories a good idea (And then
>> offering people export in old and import in new version, advertised by
>> ui_msgs)? What do other distros do?
>
> I don't think upgrading a port should upgrade any user data. If an upgrade
> of user data is necessary, the user should be advised how to do so, but it
> should be left to the user to do.

Yes, I know this is the classical mp answer. But why is this
the best way to do it? Other distros do something like this
obviously. One possible answer is that it is out of the scope
of mp, or something. But we could maybe also think a bit
about it.

We could for instance create/document a well-known variant
("migrate-data"?) which people could configure. Then every
portfile author could hook into this general approach and decide
if she wants to provide it meaningfully in a port.

Something similar could be offered for starting and stopping
services. If they are off by default that would still give people
with concerns about mp doing such things a safe environment,
but in the background maintainers could provide more seamless
procedures.

Just thinking out loud.

Florian





-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com


More information about the macports-dev mailing list