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
