On Thu, 28 Feb 2019 at 10:33, arghya bhattacharay wrote: > > In that case, you're proposing giving a choice to the user as to what build > dependencies they'd like to keep?
What I would like to offer users is a way to either: - delete all unrequested ports with no dependents - or keep build dependencies, but delete others For the sake of understanding better it would probably be most helpful to get a working macports installation with some ports installed and some updated to a later version, so that you end up with some outdated ports, and then test how "port reclaim" works. I'm pretty sure that you might find plenty of other ideas to improve it :) :) :) See also below. At the moment you can decide which dependencies to remove and which ones to keep, but you usually get a list of several hundred ports, and nobody is willing to hand-pick those. On top of that, it's currently not really user friendly to do anything but "delete all" or delete just one: you either need to list all that you want to delete, or delete all. And then delete all is the only reasonable choice if you don't want to spend a long time :) > are there Test ports for development purposes? Not that I'm aware of, but what exactly would you like to achieve? It should be straightforward to write bogus/test ports if you know what you want to do. But mostly real ports should work just fine (or better?) for testing. If you want to test outdated ports, one option would be to checkout macports-ports repository that's several months old, run portindex, install some ports from there, then switch to the latest version, run portindex again, then "sudo port upgrade outdated" (and "port outdated" before just to check). This should give you a bunch of outdated inactive ports (you could also check git history to see which ports were updated in the meantime, just to make sure that you don't install precisely those that were not). Mojca Mojca
