Tracking which ports were installed explicitly

[Andre Stechert]

Didn't see anything about counts of the implicit dependencies in the
ticket or in this thread.  The states of a port are probably
"explicitly installed", "implicit against 1 other port", "implicit
against 2 other ports", etc., right?  Otherwise, you have the
potential of setting the orphaned bit too early.  Also, the "explicit"
bit should probably be independent of the implicit dependency count.


On Wed, Dec 3, 2008 at 1:13 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> Joshua proposed that we should track which ports were installed explicitly
> (via "sudo port install x") vs. which ports were installed via dependencies.
>
> As he said in the ticket -- http://trac.macports.org/ticket/15260 :
>
>> Keeping track of which ports the user explicitly asked to be installed, as
>> opposed to those installed only to fulfil dependencies, would be quite
>> useful. It would be analogous to Gentoo's 'world'. With this information, we
>> could do things like uninstall all the ports that are no longer required
>> after uninstalling some other port.
>>
>> It shouldn't be hard to store the information by adding a magic port name
>> to the dep_map which depends on all the explicitly-installed ports. We'd
>> then need code to figure out during install whether the port was explicitly
>> asked for, and add the dep_map entry. We'd also need to change the
>> dependents check in uninstall to not complain if the only dependent is the
>> magic 'world' port.
>>
>>
>
>
> Some discussion has taken place in the ticket and I'd like to move that
> discussion to this mailing list so we can get more input, and since it's
> easier to discuss things on the mailing list without cluttering up the
> ticket. Once we reach a consensus on what should be done, a summary can go
> into the ticket.
>
>
> I mentioned the parallel with CPAN, which to my recollection has a feature
> where when you uninstall X, and if it depends on Y, and nothing else depends
> on Y, it will ask interactively if you want to uninstall Y as well. I
> pointed out that MacPorts has no interactivity at this time (except if you
> explicitly enter interactive mode by typing just "port"), and that I value
> this guarantee of non-interactivity.
>
> Rainer and I liked the idea of a new pseudo-port (I called it "unused";
> Rainer called it "orphaned" which is probably better) that you could use to
> deal with the ports that had been installed as dependencies of things which
> themselves have already been uninstalled. Then you could do the usual things
> like "port installed orphaned" or "sudo port uninstall orphaned".
>
> The idea is to have MacPorts keep track of what you installed explicitly and
> what was installed automatically as a dependency. I think it might be of
> value to be able to manipulate this after the fact, both by changing
> something from an explicitly installed port to an automatically installed
> dependency (e.g. things that you would have let MacPorts install as a
> dependency except that you had to install it explicitly to get a particular
> variant) and by changing something from an automatically installed
> dependency to an explicitly installed port (e.g. things that you let
> MacPorts install as a dependency but which you want to keep around). Though
> I'm not convinced it's essential, and maybe it can be deferred until later
> anyway.
>
> I also brought up the need to consider how this feature would affect the
> MacPorts framework/API. Probably a new pseudo-port wouldn't need any special
> changes in the API which would be good.
>
> I'd like to solicit opinions on any and all of these matters, so let the
> discussion begin!
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>