Discussion of idea: Auto-detection of build dependencies [GSoC][Application Process]

[Mojca Miklavec]

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