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.
macports-users mailing list