Branching for 2.4

Rainer Müller raimue at macports.org
Fri Dec 16 14:28:20 CET 2016


On 2016-12-16 12:47, Joshua Root wrote:
> On 2016-12-16 05:08 , Rainer Müller wrote:
>> # port diagnose
>>
>> 'port diagnose' seems completely broken. The ports tree resources do not
>> contain definitions for valid Xcode versions on macOS 10.11 or 10.12.
>> Therefore the command errors out very early and is not useful. Overall,
>> it looks like this was not tested at all recently.
>>
>> Do we still want to fix this and polish it for 2.4, or should we just
>> skip this new feature for 2.4 and move it to 2.5?
> 
> I don't think there's any harm in shipping it as-is, as it's a single
> separate action that doesn't change anything. Best case we just need to
> add some more version info, worst case we can say that diagnose is
> experimental.

It does not do harm, but announcing such a command when it is known to
be broken will be bad user experience.

I tried to look into these checks quickly, but I do not understand how
some of them are even supposed to work. For example 'port diagnose'
requires sudo, but wants to check the users PATH, which is just
incompatible.

The easiest and least-invasive way to get rid of this feature would be
to remove the action from the port client after branching. The rest of
it would be dead code, but at least the entry point would be gone.

>> # usealtworkpath / altprefix
>>
>> A few years ago I already proposed to rip out usealtworkpath and
>> altprefix completely [1], but Joshua wanted to keep it for destroot
>> testing. This feature is what enables building in user's ~/.macports
>> without sudo.
>>
>> In my opinion there is no use for this feature anymore and it just adds
>> unnecessary complexity. Now that trace mode is even working with SIP
>> again, the 2.4 release would be a another opportunity to get rid of this.
> 
> I agreed that there was no more need for this after sandboxing was
> added. I wouldn't delay the release for it though. Call it deprecated in
> this release?

Marking it deprecated by actually informing users with a message at
runtime or just with a ChangeLog entry?

>> # Update Tcl and other libraries
>>
>> We should update Tcl and the other libraries to the latest available
>> version before branching. I held this back until we resolved PR#6 [2]
>> first.
> 
> I guess you mean the latest Tcl 8.5.x. Probably a good idea.

Yes, I meant updating to the latest Tcl 8.5.x. Ignoring any of the
discussion, we can just add full compressed tarballs once again:

https://github.com/macports/macports-base/pull/11

Rainer


More information about the macports-dev mailing list