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

Reply via email to