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

[Arghya Bhattacharya]

Greetings, 

----- Original Message -----
From: "Mojca Miklavec" <mojca at macports.org>
To: "arghya bhattacharay" <arghya.b at research.iiit.ac.in>
Cc: "MacPorts Development" <macports-dev at lists.macports.org>, "Marcus Calhoun-Lopez" <mcalhoun at macports.org>
Sent: Thursday, February 28, 2019 4:24:33 PM
Subject: Re: Discussion of idea: Auto-detection of build dependencies [GSoC][Application Process]

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.

-> I did ! And I get why we need to redo the way reclaim works and why this project makes sense.
-> As far as I understand, reclaim calls 3 methods:

uninstall_unrequested
  Just takes a list of all ports installed and sorts them topologically and then checks if a port is unrequested. provides ui option to uninstall all of the $unnecessary_ports.

uninstall_inactive
  Checks all ports that are imaged and not active, sorts them topologically and provides UI option to delete them.
   
remove_distfiles
  For each of the installed port, creates $files_in_use based on the information in the portfile. Then walk_files method checks for files that aren't in $files_in_use and offers to delete or keep them


But I'm not really sure what these distfiles are? Could someone elaborate on how distfiles are useful in a macports installation and when are they used?

The Reclaim part of the project seems easy, just need to change the way $unnecessary_ports are selected based on the registry.

I also looked up the code for trace mode (portrace.tcl). But I'm facing some difficulty in understanding how it works. Ideas on where to start if I'm trying to understand how trace mode works? What I'm looking for is how Macports is "tracing" the installation process to understand the files which are dependencies.

I believe this would be a fundamental part of how I'm going to specifically identify the build dependencies.


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).

-> Yes, this makes sense. Thank you :D

Mojca




Mojca


Regards
Arghya Bhattacharya