[MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

[René J.V. Bertin]

MacPorts wrote on 20160915::23:53:47 re: "Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup"

>Changes (by ryandesign@…):
>
> * status:  new => closed
> * resolution:   => wontfix

> We've already solved this problem: whenever a port is updated in such a
> way that one of its libraries changes its install_name (including changing
> its major version), the person who updates that port shall also revbump
> all ports linking with that library so that they get rebuilt. Yes, binary

That's hardly a solution in my book, because

> packages may take some time for our buildbot to compile, or may not be
> available in all situations so users may need to compile the upgrades on
> their own systems. 

it also puts the burden and responsibility of stability and usability of a potentially huge ecosystem with a single person who can hardly be expected to have the knowledge of all the ports to revbump. 

It may be acceptable for some, and possibly even the best compromise for regular users who don't mind doing very regular updates while they turn their thumbs or do something more useful elsewhere.

> I realize you don't like this solution, but it's the
> one we've chosen for now. You're welcome to discuss it on the mailing
> list, but your proposed portgroup in this ticket is unlikely to be an
> acceptable solution.

<fr_FR> Dont acte. </fr_FR>

My proposal aims to introduce (and provide a proof of concept) of an optional other solution, which could be used by select ports and give users with specific needs an easier way to adjust the update behaviour and cycle to their requirements. Easier than backing out of an upgrade cycle that turns out to have unwelcome consequences, copy the retrieved outdated culprit ports to a personal ports tree and start over again.

It'd be more elegant if implemented in "base", with more control over which libraries get preserved from an existing install, but I think it's obvious a non-default variant should be used to activate the feature.

It'd be even more elegant if the implementation actually reactivated select files from an older software image, meaning they'd remain members of that installed version only and be removed from the system when the user uninstalls that or those older versions. I'd love to try my hand at that but it's clearly going to involve substantial changes to "base", possibly even a change to the registry database, and I'm not comfortable with that.
Maybe the additional metadata could be stored in an additional *sql file? 

If that additional metadata includes a list of which ports depend on what "outdated" libraries it should even become trivial to present a list of recommended updates, i.e. the ports that ought to be rebuilt in order to use the latest dependencies available. That's the same list of ports that would break when uninstalling a particular version of a particular dependency.

I know that users can already decide not to upgrade select ports (and back out of an unwelcome upgrade by reactivating old versions), but then you quickly end up with an increasing list of outdated ports (making it hard to see and figure out which can and should be upgraded) and at some point you almost stop upgrading (and selfupdating) at all.

R.