Default choices for port select (was: Re: py-mercurial)

[Rainer Müller]

On 05/10/12 19:53, Sean Farley wrote:
>     This is not possible as port select always needs a base file which
>     cannot be shipped with any of the selectable port options. This is why
>     we have the *_select ports; their only purpose is to install this
>     base file.
> 
> 
> Sure it is. You could just generate the files needed during the
> post-destroot phase. Something like this:
> 
> 1) loop through ${python.prefix}/{bin,etc,share,lib,libexec}
> 2) output into 'select' files: base, none, etc.

And which port is supposed to install these files?

Multiple ports want to provide options, but only one can claim ownership
of the base file. The base file need to be retained even when I
uninstall any of the ports providing options such that the other options
can still be chosen.

> Well, couldn't something be done in the post-activate stage? "if nothing
> selected, then select this one"

Yes, the select port group could supply such a default post-activate phase.

In some cases we also have system-provided option for which we decided
they should be kept as the default. For example, when python27 is
installed as a dependency of something else, should this change the
'python' executed in the shell or would the user recognize this as
unexpected behavior? At the moment, the default would still be
/usr/bin/python as no symlink has been placed in /opt/local/bin at all.
Same is true for gcc4*/clang where the system-provided compiler is
usually the better choice as it has been tested and is considered stable.

However, there are other ports installed as a dependency that change
what is executed by default - for example when git or svn are required
for fetching. Also, ports like perl5* install as 'perl', overriding
/usr/bin/perl in PATH. These ports do not provide a select option
anyway, so is this the expected behavior?

I am undecided on what the default option should be here...

Rainer