<div dir='auto'><div>Thanks for the prompt reply !<br><div><br><div class="elided-text">On Feb 28, 2019 1:05 PM, Mojca Miklavec <mojca@macports.org> wrote:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On Thu, 28 Feb 2019 at 06:25, arghya bhattacharay
<br>
<arghya.b@research.iiit.ac.in> wrote:
<br>
>>
<br>
>> Hello all,
<br>
>>
<br>
>> On Feb 28, 2019 4:21 AM, Mojca Miklavec <mojca@macports.org> wrote:
<br>
>>
<br>
>> Dear Arghya,
<br>
>>
<br>
>> Welcome in the MacPorts community!
<br>
>
<br>
>> On Wed, 27 Feb 2019 at 17:37, Arghya Bhattacharya wrote:
<br>
>> >
<br>
>> > - Is the project in reference to changing "port reclaim", more specifically change port reclaim to not delete build dependencies?
<br>
>>
<br>
>> These two are not related, but both tasks could be worked on. They
<br>
>> potential mentor for any of those tasks would be Marcus, so I hope
<br>
>> that he jumps in with more relevant answers.
<br>
>>
<br>
>> I assume that you took auto-detection of build dependencies from our
<br>
>> list of ideas, and the "port reclaim" from a recent discussion on the
<br>
>> mailing list?
<br>
>
<br>
> Yes, I went through the archives hoping to find more insight into the projects from the discussions.
<br>
>
<br>
> Would  Port reclaim be a separate project in that case?
<br>

<br>
It's a different and relatively independent task, but either of those
<br>
two tasks is probably not enough on its own to fill the entire summer,
<br>
so these two could easily be combined.
<br>

</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">-> That's what I was trying to point at. I'll make sure to device a plan to work on both these issues when I write my proposal.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
> Seems like an extension of computing build dependencies to me. Maybe I'm missing the point here.
<br>

<br>
# RECLAIM
<br>

<br>
"port reclaim" was a GSOC project a few years back:
<br>
    https://trac.macports.org/wiki/ksammons
<br>

<br>
What it does is take care of removing stuff you no longer need.
<br>
If you've been using MacPorts for a long time and never run a cleanup,
<br>
old versions start accumulating on the machine.
<br>

<br>
The "port reclaim" command interactively guides you through the
<br>
process of removal of those files:
<br>
- all the sources you no longer need
<br>
- all the binary packages that are no longer active</p></blockquote></div></div></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
- all the installed packages that you have never explicitly requested
<br>
and that have no dependent ports
<br>

<br>
The last one is sometimes problematic and was recently discussed on the list.
<br>

<br>
For example, if you install some port that depends on perl5.26, then
<br>
update the port which now requires perl5.28 (but you never actually
<br>
need perl5.26 yourself), the "port reclaim" would offer you to remove
<br>
perl5.26.
<br>

<br>
This is all fine and well, except that it might also offer you to
<br>
remove the latest version of compiler (which you have painfully built
<br>
yourself on a super slow 15-year old PowerPC machine) or git or
<br>
something else that will be needed as soon as you update your next
<br>
port. Technically the compiler is not needed to run the software, but
<br>
it's painful to have to rebuild it next time when you update any other
<br>
port.
<br></p></blockquote></div></div></div><div dir="auto">-> In that case, you're proposing giving a choice to the user as to what build dependencies they'd like to keep?</div><div dir="auto"><br></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
To fix this behaviour you may need to improve the database of
<br>
installed ports (and fix the install phase, so that it writes the
<br>
necessary information to the database), so that it would be easy
<br>
enough to figure out whether any installed ports have a build
<br>
dependency on the port in question. I believe we are currently lacking
<br>
that information in the database, but all the information is already
<br>
encoded in the Portfiles, so it's not like you would need to invent
<br>
that information yourself. And once you have that information in the
<br>
database, fix port reclaim, so that it can easily include or exclude
<br>
removal of such build dependencies.</p></blockquote></div></div></div><div dir="auto"></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
# BUILD DEPENDENCIES
<br>

<br>
This is a different scenario. Suppose that you want to package a new
<br>
piece of software (or update to a new version which just switched to
<br>
completely different dependencies). In this case you need to assume
<br>
that all the information about dependencies that you might have in
<br>
your Portfile is plain wrong (either lacking or listing too many
<br>
dependencies; with "port reclaim" on the other hand you assume that
<br>
information in the Portfile is 100% correct).
<br>

<br>
The idea is to observe which files are being accessed during the
<br>
installation process, then consult port registry (database) to tell
<br>
you to which port the accessed file(s) belongs, and finally assemble
<br>
the list of ports that have been used during the installation, and
<br>
report that list to the user, so that the user would manually compare
<br>
the reported list of dependencies versus the dependencies specified in
<br>
the Portfile. Or well, the "port --something install" would tell the
<br>
user:
<br>
- here's a list of dependencies that you declared and were used: ...
<br>
- here's a list of dependencies that were used, but are missing in the
<br>
Portfile: ...
<br>
- here's a list of ports that you declared, but were never accessed: ... </p></blockquote></div></div></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
The ideas how to start should come from the way "trace mode" is
<br>
implemented. That one forbids you to access dependencies that were not
<br>
declared beforehand, which is a slightly different strategy, but
<br>
similar nature of approach. </p></blockquote></div></div></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
> Any Port would have compulsory dependencies and optional dependencies.
<br>
> So the issue is with detecting which optional dependencies are being used?
<br>

<br>
The issue is that the first time you try to package software you don't
<br>
even know which dependencies are compulsory before you spend a lot of
<br>
time researching, checking the sources, configure script, Makefiles
<br>
etc. Even if you don't specify any dependencies at all, the software
<br>
will still build.
<br>

<br>
At this point I would ignore the notion of compulsory vs. optional
<br>
dependencies, that's for later. Consider any dependency that you want
<br>
a compulsory dependency. It's just that currently we have absolutely
<br>
no idea which dependencies are needed. We go from assumption that the
<br>
Portfile is incomplete.
<br></p></blockquote></div></div></div><div dir="auto">-> This makes sense. I agree with you now. The goal should be to find out ALL files that are being accessed during installation of a port and find which ports the files belong to. </div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
> How does the problem persist with compulsory dependencies too? Aren't they listed in the Port configuration files?
<br>

<br>
If talking about this project idea, you need to assume that the
<br>
dependencies are not listed anywhere.
<br>

<br>
>> * many dependencies link opportunistically: they'll be used if
<br>
>> present, and skipped if absent.
<br>
>
<br>
> these are the dependencies to install the Port or the ones needed to run them?
<br>

<br>
Dependencies needed to run the port (like an optional python library)
<br>
are not problematic. They might be missing during the build, but you
<br>
may install that library any time later and you'll get full
<br>
functionality.
<br>

<br>
Opportunistic linking is a problem during the build.
<br>

<br>
It's problematic if you have software that will link against Qt if Qt
<br>
is installed, but install without complaining (and crippled /
<br>
different functionality) when Qt is missing. I don't know what
<br>
software you know, but if you have ever used "gnuplot": it can either
<br>
work with Aqua, with X11, with Qt, with wxWidgets ... any of those
<br>
will work, but if you don't have X11 or Qt or wxWidgets, it will just
<br>
build without support for that UI. If you install X11 after installing
<br>
gnuplot, you won't be able to use gnuplot with X11, but if you install
<br>
X11 before gnuplot, you would be able to use it. (The portfile for
<br>
gnuplot doesn't have that issue since we explicitly enable and disable
<br>
functionality, it's just to demonstrate what I meant.)
<br>

<br>
>> We would want the "port" command to automatically report which
<br>
>> dependencies were used during the build (either build dependencies
<br>
>> like pkg-config or libraries, ...)
<br>
>
<br>
> By keeping track of what files are accessed during build ?
<br>

<br>
Yes.
<br>

<br>
>> (2)
<br>
>> We recently discussed the issue that "port reclaim" removes build
<br>
>> dependencies. This would be also nice to fix, yes.
<br></p></blockquote></div></div></div><div dir="auto">-> I think this could be the second half of the project. I'd like to start with developing on identification of the build dependencies first.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
>
<br>
>
<br>
> So, if AutoDetecting & storing all dependencies of a port becomes a method attribute of the Port.
<br>

<br>
What do you mean by method attribute?
<br>

<br>
> Then this would be as trivial as accessing the list on a trigger of port reclaim?
<br>

<br>
I'm not sure what you asked, but I tried to explain above. Yes, you
<br>
need to read from the database and simply don't let reclaim delete the
<br>
build dependencies (you must have assembled that list/database
<br>
before). This step should be easy.
<br></p></blockquote></div></div></div><div dir="auto">-> I have clarity on what the task demands to a certain extent now. Thanks ! :D</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
> I've used the git method of install, updated head of my installation to my fork of port-base.
<br>
> I just don't find any instructions on how I can compile my changes to the tcl scripts so I can test the commands with my changes ?
<br>

<br>
In case this particular question / answer gets too long & unresolved,
<br>
please open a new thread on the mailing list. There might be some
<br>
people who are not particularly interested in GSOC and might skip this
<br>
too long thread, but they might be able to help you with this small
<br>
independent question.
<br>

<br>
What I usually did was to simply install MacPorts from the installer
<br>
first (just to get everything in place; but also because I had MP
<br>
installed long before I even started touching anything), and then do
<br>
    ./configure
<br>
    make
<br>
    sudo make install
<br>
from the git clone of macports-base. That would overwrite the existing
<br>
MacPorts installation and you'll start using your own changes.
<br>

<br>
If you modify something, just run "make && sudo make install" again.
<br>

<br>
You probably don't need to install from package first, you just need
<br>
to make sure that you have macports-ports somewhere. By default it's
<br>
in
<br>
    /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports
<br>
but to me it's useful to have a git clone instead and point to it from
<br>
    /opt/local/etc/macports/sources.conf
<br></p></blockquote></div></div></div><div dir="auto">-> I'll open a new thread in case I face difficulty. But in my case I think make&& make install should suffice to what I'm looking for right now.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
I would probably start by
<br>
    sudo port selfupdate # or one of alternatives like sync
<br>
    sudo port install any-port-of-your-choice
<br>
and keep playing with the port command. You could increase revision of
<br>
the just installed port, run install or upgrade again to get one
<br>
inactive port etc.
<br></p></blockquote></div></div></div><div dir="auto">-> are there Test ports for development purposes? </div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
Mojca
<br>
</p>
</blockquote></div><br></div></div></div>