Fetching unpinned releases of verbs is brittle

[9ary]

It was brought to my attention that winetricks can download the latest release of some verbs from github without them being explicitly packaged. Those I could find from a quick lookup in the source:

• dxvk
• vkd3d-proton
• gallium-nine

There are several problems with this:

• upstreams can make changes that suddenly break the default behavior of winetricks
  • this can lead to situations where upstream wants to maintain backwards compatibility, and is therefore severely constrained in the changes they can make; see Misc cleanups iXit/wine-nine-standalone#154
• there is no coordination between upstream releases and winetricks releases, which means rolling release distros will not package fixed versions unless they decide to patch winetricks or pin an untagged commit
• this subverts the expectations of "stable" distro users such as Debian who specifically choose to remain on the same software versions for a long time

Regarding the first point, there should at least be a way for upstreams to tag breaking releases, giving winetricks a chance to catch up without breaking in the meantime. Alternatively, upstreams should ship their own install script that winetricks would execute, rather than do its own thing.

As far as distros are concerned, it should be possible for them to disable this behavior entirely, and there should be some kind of policy to quickly tag a new release when updating verbs with a fast release cycle.

[gverm]

At least for DXVK and gallium-nine, there are verbs which specify which release you want to install. The "general" verbs potentially having these issues seems like a normal side-effect of such a bleeding edge verb IMO. Or am I misunderstanding the issue?

[9ary]

The problem is that this is the default behavior, and upstreams can break it outside of winetricks's control. It also subverts the expectations of distros like I said.

[gverm]

Yes, I understand, but that being the default behavior for a "bleeding edge" verb is normal IMO. If you want to install gallium-nine or DXVK in a stable way, you can use the tagged verbs.

[9ary]

Can you define "bleeding edge" in this case?

gallium-nine-standalone for example is just a shim that doesn't see a lot of development activity, the actual implementation is part of mesa, it has been upstreamed for a long time and is being shipped by distros.

The problem occurs specifically when using tagged releases of winetricks or a distro package. In those cases, I would expect the default to be pinned, with an explicit opt-in for the latest release.

[gverm]

The "dxvk", "vkd3d-proton" and "gallium-nine" verbs are made to always install the latest versions of these components, whatever they may be. Verbs like these are brittle by definition.

For stability we have verbs like "dxvk2010", "dxvk1091", "galliumnine09", "galliumnine08", etc. These always use pinned, known tagged releases of these components.

So using the general, untagged verbs is always discouraged unless you are prepared to handle potential breakages.

[9ary]

This seems completely backwards to me. When installing a package from any other distro, I expect to install the latest version that was packaged by my maintainers. I would never in a million years want my package manager to go to github and blindly download the latest release, unless I specifically choose to use a package that's designed to do that.

Is it even possible to ask for whatever is the latest pinned version currently?

Here's what I would really expect:

• dxvk2010 installs that specific version
• dxvk is a moving pin, regularly updated to the latest
• dxvk_latest is the current behavior (fetches from github)
• a hypothetical dxvk_dev would fetch some kind of nightly build, for example the latest successful build from the actions tab

[gverm]

@9ary I do agree that general verbs just blindly fetching the latest release is not the best idea. Your idea to have a "_latest" variant that is the current behavior seems good to me. Do note that having it this way is a bigger burden on the maintainer(s), as they have to keep changing the version that the general verbs use.

Now that I think about it, winetricks used to have a "dxvk_master" verb that kinda did what you are describing as "dxvk_dev", but it broke because the CI that was used to grab artifacts from was discontinued.

I do want to clarify, winetricks is not a package manager and it doesn't package any of these components itself. In the general verbs it's just depending on the fact that if a component releases a release, that it's good to go to download and use.

@austin987 What do you think? It does seem like a good idea to have a verb that always points to the latest known (to us) release. I'm in favor of moving the current behavior to a "_latest" or "_dev" variant and then changing the general verbs to point to the latest release that we know about and have a separate verb for.

[9ary]

@9ary I do agree that general verbs just blindly fetching the latest release is not the best idea. Your idea to have a "_latest" variant that is the current behavior seems good to me. Do note that having it this way is a bigger burden on the maintainer(s), as they have to keep changing the version that the general verbs use.

As far as I can tell, general verbs tend to just be aliases for the latest pins, which are already being maintained. I can understand that you consider the upstream release pace to be a maintenance burden though. I just think the default behavior should be as unsurprising as possible, and currently that's not the case.

Now that I think about it, winetricks used to have a "dxvk_master" verb that kinda did what you are describing as "dxvk_dev", but it broke because the CI that was used to grab artifacts from was discontinued.

I do want to clarify, winetricks is not a package manager and it doesn't package any of these components itself. In the general verbs it's just depending on the fact that if a component releases a release, that it's good to go to download and use.

At a technical level, yes. However for practical purposes, it behaves like one.

Thanks for considering my suggestion.

[austin987]

@austin987 What do you think? It does seem like a good idea to have a verb that always points to the latest known (to us) release. I'm in favor of moving the current behavior to a "_latest" or "_dev" variant and then changing the general verbs to point to the latest release that we know about and have a separate verb for.

Seems reasonable, but a couple concerns:

• For users, it's a change in behavior. Should probably have a message notifying the user about the change (when calling affected verbs), and a note to use _latest/_dev if they want the old behavior.
• I'm more concerned about the maintenance burden. If the 'master' verb has to be updated every time there's a release, it's almost certainly going to get out of sync at some point.

[gverm]

@austin987 For the maintenance burden we could do the same as for the change in behavior, i.e. show a message highlighting the fact that this verb might be out of date and to use the "_latest" variant if they want the last upstream release.

That doesn't alleviate the maintenance burden of having to review + merge more PRs of course.

[9ary]

This could be worth automating for what it's worth, have a github action check for a new release and do some basic sanity checks. If anything is not as expected, CI fails, otherwise it can automatically commit the changes.

This means that most of the time you won't have to do anything more than currently, other than verify everything is okay when tagging a release. And it would still be an improvement.

[austin987]

@austin987 For the maintenance burden we could do the same as for the change in behavior, i.e. show a message highlighting the fact that this verb might be out of date and to use the "_latest" variant if they want the last upstream release.

I don't think that solves it; my concern is that dxvk will point to 1.2.3, then someone will add release 1.2.4, but not update the dxvk verb to use that version. Ideally it would be automatically derived, by doing something like winetricks dlls list | grep ^dxvk | sort -V | tail -n1, but it's not quite that simple.

That doesn't alleviate the maintenance burden of having to review + merge more PRs of course.

Of course ;)

[bb010g]

I don't think that solves it; my concern is that dxvk will point to 1.2.3, then someone will add release 1.2.4, but not update the dxvk verb to use that version. Ideally it would be automatically derived, by doing something like winetricks dlls list | grep ^dxvk | sort -V | tail -n1, but it's not quite that simple.

In the floating version case, installation support should be located somewhere that can float along. This could be the respective upstream or a separate Winetricks repository.

[lizthegrey]

confirming vkd3d appears to detect 2.3 when 2.11.1 is in fact the latest. 2.3 does not work with modern wine 9.x