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"
