[MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

[René J.V. Bertin]

On Friday September 16 2016 16:06:54 Rainer Müller wrote:

>Moving the discussion to macports-dev as this is about the
>implementation, nothing users should care about.

You're not entirely right: users can and should care about ease of updating. I posted to macports-users on purpose, to get the largest possible awareness.

>That would be solved with dependency resolution using a SAT solver and
>version information in dependency specifications. We already started to
>work on that in last GSoC.

I'm not entirely sure if versioned dependencies are a solution to this particular problem. They shouldn't even become necessary when old runtime libraries can be left around; any port using them that gets updated will use the latest version. I don't see how you could end up in a situation where a non-rebuilt/reinstalled port that worked with a previous version will stop to work if you upgrade that dependency while keeping the required old runtime libraries around. A bump in the required dependency version will by definition be a result of an upgrade of the dependent.

>Putting the files into the destroot for the new archive is the wrong
>solution to this problem.

But the only workable workaround at the moment, as far as I can tell.
Even if it'll remain acceptable only in custom ports trees I'd still appreciate suggestions to improve it.

>Libraries that would not be replaced, but still have linking information
>need to be preserved on disk and in the registry indicating which port
>they belonged to. After all other ports linking to the files are
>upgraded, they can be safely removed.

Are you thinking of an automatic feature here? You're right that this should be feasible but that'd be so elegant even I didn't dare dreaming of it :)

>version) changes. This does not happen that often and as long as the
>major part of ports comes from our ports tree, the current solution of

It happens often enough with far-reaching enough consequences, in my perception!

>and cannot introduce the rev-bump at the same time. However, the
>automatic scanning in rev-upgrade will detect the problem and either
>upgrade the broken port with a new binary archive or eventually rebuild
>the port locally, ensuring the user has a working installation of all ports.

And hopefully for him/her, one that doesn't have any ports that require manual rebuilding, have pending changes, or any other whatever-it-is that means it shouldn't be upgraded completely automatically.

>needs to be done in base. As you said, that will require changes to the
>registry format. As we currently handle upgrade as a completely
>transparent deactivate old/activate new cycle, that would also require
>significant changes to the internal phases.

I know next to nothing about db internals, so I have no idea if one can store new data fields in a database and still keep it forwards compatible (i.e. old db file readable by the new code). I'd hope this is or can be more or less transparent, but if not, couldn't that new data be stored in an additional file?
And wouldn't that reduce the overhead of operating on a single huge db file, at least in theory?

R