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

[Clemens Lang]

Hi,

On Sat, Apr 07, 2018 at 07:16:37AM -0500, Ryan Schmidt wrote:
> 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.

Sure, but would you propose adding this hack to the conflicts-build
PortGroup if $name == $conflicting_port?


> * 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.

Yet we already deactivate ports right before activating the new version,
so there already is a time window where the files of a port are missing,
even though that time window is arguably shorter than if the build was
happening at the same time. Note, however, that even deactivation and
activation can take a long time for large ports. In essence, I think
users should expect files of a port to vanish for a certain duration of
time while it is being upgraded.

I don't think extending this period is too much of a problem, especially
with smaller ports.


> * 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.

Yes, I agree, that's a problem. Ideally, users would take care of
failing builds immediately, but we all know that's not happening.
Unfortunately we don't have a way to register a callback to be executed
when a build fails. If we had a way to register a 'on-build-failed'
callback, we could change the conflicts-build PortGroup to automatically
deactivate conflicting ports and re-activate them on error.


> 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.

I think the case of self-conflicts is a special one w.r.t. to automatic
deactivation of the conflicting ports, because I don't think it is
counter-intuitive that the old version of a port might no longer be
active if the build of a newer version failed. The same does not hold
for build conflicts with other ports.


> 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.

I think we should provide a way to register an on-error callback (to
allow reactivating conflicting ports) and then put the change into the
conflicts-build portgroup. Until then, I think this approach is the
least disruptive to users.


> 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.:

Actually, whether a build conflicts with files installed by the same
port is usually not a function of the old version, but only the new one,
so this comparison isn't entirely correct. I just hope to get this bug
fixed before the next upgrade.

Consequently, I don't think that the conflicts_build portgroup needs to
support version numbers (and strictly speaking, the hack I added to the
jack port doesn't need it either).

-- 
Clemens