Github mirror for Calibre is a bad idea

[apetresc]

So, #9942 switched the Calibre mirror directly to the GitHub release installers. Unfortunately, as you can see, whether it's automatically done by GitHub or manually by the maintainer, the GitHub release mirror only hosts installers for the most recent release.

What this means is that every single week (the current Calibre release schedule), homebrew-cask's calibre recipe breaks:

$ brew cask install calibre
==> Downloading https://github.com/kovidgoyal/calibre/releases/download/v2.20.0/calibre-2.20.0.dmg

curl: (22) The requested URL returned error: 404 Not Found
Error: Download failed on Cask 'calibre' with message: Download failed: https://github.com/kovidgoyal/calibre/releases/download/v2.20.0/calibre-2.20.0.dmg

While I understand that the old mirror was slow for some people, the current one is broken for everyone unless homebrew-cask updates its links every single week.

[vitorgalvao]

This is an old matter.

Does Calibre still warn you of new versions but not auto-update? Because in that case an update would require a brew uninstall calibre && brew install calibre every time instead of just (in the future) brew cask upgrade.

It seems we can’t really win, here. Unless, and this is just now occurring to me, we use github releases as an appcast, which will allow us (again, in the future), to update this way more easily. This should also be extrapolated for every cask with a github releases url. Opened a PR to get the ball rolling. That sounds like the best option. In the meantime, we’ll have to keep doing it manually.

[ghost]

This can be solved by using metalinks instead/as a supplement to the developer-hosted binary. See #10264

[1zaman]

The main host (http://download.calibre-ebook.com) loads at max speed for me, not sure what the issue is with it. Note that this is an issue for new installs as well as upgrades. Even a (reasonable amount of) reduction in download speed should be preferable to potential breakage.

Does Calibre still warn you of new versions but not auto-update?

I only use the ebook viewer, but I think so.

Because in that case an update would require a brew uninstall calibre && brew install calibre every time instead of just (in the future) brew cask upgrade.

brew cask install --force calibre works fine for me.

[vitorgalvao]

Even a (reasonable amount of) reduction in download speed should be preferable to potential breakage.

It is not reasonable, and this way is better for the future (appcasts).

brew cask install --force calibre works fine for me.

That leaves you with old versions lingering. Also --force isn’t a solution: we’re using it as a workaround but a proper way upgrade is needed.

[1zaman]

It is not reasonable

It's working perfectly for me. Perhaps they fixed the issues; it's their main download link after all.

and this way is better for the future appcasts.

Until that future actually comes though, we should not implement changes that would constantly break without it.

That leaves you with old versions lingering.

Homebrew mainline also doesn't automatically delete the old versions upon upgrade, and that's the correct thing to do in my opinion. It's always good to have some known good version of applications to fall back to in the case of issues. That's one of the main benefits of using a package manager.

Also --force isn’t a solution: we’re using it as a workaround but a proper way upgrade is needed.

Agreed.

[vitorgalvao]

It's working perfectly for me. Perhaps they fixed the issues; it's their main download link after all.

Will have to check. Won’t be able to do it in the next few days, though. You can open an issue, if you’d like.

Homebrew mainline also doesn't automatically delete the old versions upon upgrade, and that's the correct thing to do in my opinion. It's always good to have some known good version of applications to fall back to in the case of issues. That's one of the main benefits of using a package manager.

I completely disagree with that reasoning. Following homebrew in that particular case is a mistake as we deal with very different things. See #13201 for a deeper explanation.

[1zaman]

You can open an issue, if you’d like.

You're welcome to reopen this issue if you wish. I can also open a pending pull request if desired; maybe some other maintainer can verify the host if you're busy.

I completely disagree with that whole reasoning. Following homebrew in that particular case is a mistake as we deal with very different things. See #13201 for further reasonings.

The only arguments I see there for removing linking is that a few applications expect hardcoded locations, or that having different versions of GUI apps is "far from the norm" (of course it is far from the norm in manual non-managed installations). Anyway, I have added a comment there explaining my position.

[vitorgalvao]

You're welcome to reopen this issue if you wish.

No, I won’t reopen the issue. This issue has been replied to with the information we had at the time. If new details have come to light, then a new issue is needed. Reopening old issues leads us nowhere, no one wants to read the old, now irrelevant information again. Again, if you want to, you can open a new one (please link to this one).

The only arguments I see there for removing linking is that a few applications expect hardcoded locations, or that having different versions of GUI apps is "far from the norm"

I’ve already replied there. But if that is the only thing you took from it, then it’s confirmed you lack context for all the issues caused by linking as opposed to copying, and you can’t get those without involvement and time.