[macports-ports] branch master updated: jack: Fix upgrade path from jack1

[Ryan Schmidt]

On Apr 7, 2018, at 06:20, Clemens Lang wrote:

> On 7 Apr, 2018, at 09:50, Ryan Schmidt wrote:
> 
>>> +# deactivate hack added 2018-04-06
>>> +pre-configure {
>>> +    # When upgrading from jack1 to jack2, the build can fail outside of trace
>>> +    # mode because waf puts the CPPFLAGS at the beginning of the compiler
>>> +    # command line. This was fixed in waf 1.9.0, but jack2 ships waf 1.8.17.
>>> +    #
>>> +    # Instead of using the conflicts-build portgroup, use a deactivate hack to
>>> +    # force-deactive the old version before building, which should solve the
>>> +    # issue.
>>> 
>> 
>> Why handle this port differently from other ports that have this problem (where
>> we use "conflicts_build ${name}")?
> 
> That was my initial idea as well, but it requires user interaction, which is not
> ideal for a port upgrade. I hope to get this fixed by upstream for the next update
> so that this is a one-shot solution that can be removed again with the next new
> version.

I still think jack should not handle this differently from other ports. If we want automatic upgrades for ports that have build conflicts with themselves, then we want that for all such ports, not just for jack.

As I recall, the reasons why we are not currently doing automatic upgrades when build conflicts exist are:

* We want the user to be in control of when their ports are active or inactive. Deactivating a port the user is using could cause problems for the user, so we want the user to explicitly request port deactivation.

* In the case of a build conflict, the problem port needs to be deactivated for the duration of the build. For some ports, or on some user systems, that might be a long time. We don't want to leave a port deactivated for a potentially long time without the user's knowledge or consent.

* The build could fail. If so, the problem port would be deactivated indefinitely, until the user noticed it and reactivated the port. This doesn't seem like a good condition to place the user's system into.

The conflicts_build portgroup was designed for ports that have build conflicts with other ports. The idea that a port could have a build conflict with itself was something of an afterthought, and perhaps not all of the reasoning above applies as much in that case.

If we consider it acceptable to deactivate a port for a longer period of time than usual when a user has requested an upgrade of that port, and if we don't consider it to be catastrophic that in the case of a build failure of that port, it will be indefinitely deactivated, then we could use the deactivate hack as you've done here, but we should use it in all ports afflicted by this problem.

Ideally the code would only need to go into the conflicts_build portgroup, but there's a version number in your code -- you only deactivate jack versions earlier than 1.9.12. Maybe the conflicts_build portgroup needs to be enhanced to allow specifying port versions, using a syntax similar to the compiler_blacklist_versions portgroup, e.g.:

conflicts_build-append "${subport} < 1.9.12"