port upgrade outdated order

[Chris Jones]

On 04/03/15 15:57, Mihai Moldovan wrote:
>> On Wednesday March 04 2015 08:58:17 Chris Jones wrote:
>>> ports themselves cannot opt in or out, and nor should they be able to.
>>> Its up to the user running the port command to decide.
> That's too dogmatic. I have presented a case where the options are
> either using trace mode to successfully build ports (ports in the
> conflicts_build group which conflict with themselves) or fail. In that
> case, trace mode has to be forced for this particular port if no
> preference has been specified. If the user explicitly disables trace
> mode via a command line switch (which does not exist yet, as it's not
> the default option or even one that could be enabled within
> ports/portgroups...), execution will fail like it does today, but the
> request should be honored.

OK, I'll rephrase then. It seems OK for a port to opt into tracemode, if 
needed to fix bugs like this, but if the user has tracemode globally 
disabled ports should not be allowed to opt out.

Personally though, I still it better to just enabled trace mode by 
default globally, which will just naturally soak up all these cases. If 
a user then decides to globally opt out, thats their concern.

>
> I'd make one exception from this rule: a setting in macports.conf should
> be overrideable by ports/portgroups (especially for the use case I
> mentioned when the possible ways to go are TRACE MODE or FAIL.)
> This also holds for positive settings for ports, which are known to fail
> in trace mode by the maintainer.

I would argue only with the above restriction. Opting in is perhaps 
fine, but not out.

Chris

>
> If absolutely need-be, the modes could also be "force-on, on, off,
> force-off", but force-on and force-off can be handled by -t (real
> "enable trace mode" switch)/-T (currently imaginary "disable trace mode"
> switch) just fine, so we don't need anything non-boolean in macports.conf.
>
>
> On 04.03.2015 11:37 AM, René J.V. Bertin wrote:
>
>> You have a lot of faith in this mode, and the extent to which it is possible to let it handle each and every case appropriately for each and every (potential) port out there.
>
> Yes, we do. Because trace mode is doing the right thing™. Yes, the name
> is kind of misleading. It stems from the fact that it uses the
> "darwintrace" library to implement its functionality and override
> syscalls (like dtrace.)
>
> It's really a very strict sandbox, though, not a tracing utility per se.
>
>
>> Maybe it is possible so there's indeed no need for allowing opt-out, but as Mihai also said, there are enough examples of cases where we'd want opt-in (if the user didn't specify a setting) or at least a warning if the user opted out but the port requires it.
>
> See above.
>
>
>
> Mihai
>
>
> P.S.: could you please fix your client to not always add "Undisclosed
> Recipients: ;"? I have to remove that every single time I answer to any
> of your posts.
>
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>