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

[Ryan Schmidt]

On Apr 7, 2018, at 12:35, Clemens Lang wrote:

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

I am saying that *if* the problems I outlined previously are not considered to be a major problem (and I'm not yet sure about that), *then* yes, the deactivate hack would be added to the conflicts_build portgroup for use when the conflicting port is $subport.


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

Perhaps you're right.

But there's also the chance that the user might be running "sudo port configure" or "sudo port build" or "sudo port destroot". Granted, most users wouldn't do that, but if a user did, then they wouldn't expect the installed copy of the port to deactivate itself, since they did not run "sudo port upgrade". 


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

In my case, it could easily be that I tell the computer to upgrade a port, and then walk away for awhile. When I come back to the computer, I may have forgotten what I was doing before, switch to a different task, and not see the terminal window with the failed build until much later. It may get buried under other terminal windows or tabs.

I also want to point out that the "outdated" pseudoport only contains those outdated ports that are also active. If a port like jack that behaves this way is outdated, and the user starts the upgrade with "sudo port upgrade outdated", and the build of this port fails after having deactivated its previous version, then the next time the user runs "sudo port upgrade outdated", it won't try to build this port again. The user would have to name it explicitly, and the user may not be savvy enough to do that. In fact we actively encourage users not to upgrade individual ports (so as not to be left in a partially updated state) and recommend users always run "sudo port upgrade outdated". So this change could adversely affect users who follow that advice.

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

Right, if we had that, that could solve the problem.


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

I just think it's important to note that that's not how MacPorts has behaved before. If a port build fails, you can currently be assured that the previous version of the port is still installed and active (and ideally still working, though of course that might not necessarily be so). That's a nice assurance to have.

> The same does not hold
> for build conflicts with other ports.