https://trac.macports.org/ticket/51689
Moving the discussion to macports-dev as this is about the implementation, nothing users should care about. On 2016-09-16 10:06, René J.V. Bertin wrote: > 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. 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 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. Overall, handling these kinds of upgrades could be improved. You are correct that the proposed way would be what other package managers do, for example Gentoo's portage: https://wiki.gentoo.org/wiki/Preserve-libs Putting the files into the destroot for the new archive is the wrong solution to this problem. 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. This problem will only appear when the SONAME (or dylib compatibility 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 rev-bumping works. The problem exists mainly for custom ports trees with ports linking with the main ports tree. We have no control over these 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. There is really no way to add such a functionality in a port group, it 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. Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev