<div dir='auto'><div>Also,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 8, 2019 5:48 PM, Arghya Bhattacharya <arghya.b@research.iiit.ac.in> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Greetings, 
<br>

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

<br>
On Thu, 28 Feb 2019 at 10:33, arghya bhattacharay wrote:
<br>
>
<br>
> In that case, you're proposing giving a choice to the user as to what build dependencies they'd like to keep?
<br>

<br>
What I would like to offer users is a way to either:
<br>
- delete all unrequested ports with no dependents
<br>
- or keep build dependencies, but delete others
<br>

<br>
For the sake of understanding better it would probably be most helpful
<br>
to get a working macports installation with some ports installed and
<br>
some updated to a later version, so that you end up with some outdated
<br>
ports, and then test how "port reclaim" works. I'm pretty sure that
<br>
you might find plenty of other ideas to improve it :) :) :)
<br>
See also below.
<br>

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

<br>
uninstall_unrequested
<br>
  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.
<br>

<br>
uninstall_inactive
<br>
  Checks all ports that are imaged and not active, sorts them topologically and provides UI option to delete them.
<br>
   
<br>
remove_distfiles
<br>
  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
<br>

<br>

<br>
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?
<br>

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

<br>
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. </p></blockquote></div></div></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

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

</p></blockquote></div></div></div><div dir="auto">Is there anything specific that distinguishes build dependencies from others?</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>

<br>
At the moment you can decide which dependencies to remove and which
<br>
ones to keep, but you usually get a list of several hundred ports, and
<br>
nobody is willing to hand-pick those. On top of that, it's currently
<br>
not really user friendly to do anything but "delete all" or delete
<br>
just one: you either need to list all that you want to delete, or
<br>
delete all. And then delete all is the only reasonable choice if you
<br>
don't want to spend a long time :)
<br>

<br>
> are there Test ports for development purposes?
<br>

<br>
Not that I'm aware of, but what exactly would you like to achieve?
<br>
It should be straightforward to write bogus/test ports if you know
<br>
what you want to do.
<br>

<br>
But mostly real ports should work just fine (or better?) for testing.
<br>
If you want to test outdated ports, one option would be to checkout
<br>
macports-ports repository that's several months old, run portindex,
<br>
install some ports from there, then switch to the latest version, run
<br>
portindex again, then "sudo port upgrade outdated" (and "port
<br>
outdated" before just to check). This should give you a bunch of
<br>
outdated inactive ports (you could also check git history to see which
<br>
ports were updated in the meantime, just to make sure that you don't
<br>
install precisely those that were not).
<br>

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

<br>
Mojca
<br>

<br>

<br>

<br>

<br>
Mojca
<br>

<br>

<br>
Regards
<br>
Arghya Bhattacharya
<br>
</p>
</blockquote></div><br></div></div></div>