Rename qt to qt4 about homebrew-qt4

[ilovezfs]

@cartr thanks for your patience. Homebrew/brew#1770 is now fixed.

[MikeMcQuaid]

Actually qt@4 would be preferable given our new incoming versioning scheme 👌

[cartr]

I appreciate the advance notice! To be honest, renaming qt to qt4 and qt5 to qt seems like something that could cause a lot of problems for users. Has a "rename a package on top of a previous one and rename the old one to avoid conflicts"-type change ever been done before in Homebrew? In particular, I'm worried about these scenarios:

• If someone upgrades from a state where qt is Qt4 and qt5 is Qt5 to one where qt4 is Qt4 and qt is Qt5, will they have the same version[s] of Qt that they did previously? (If Homebrew naively tried to upgrade from the old qt to the new qt, for example, it would switch from Qt4 to Qt5 and stuff would break.)
• Will external software that depends on Homebrew-installed Qt4 still build correctly and not try to link against homebrew/core/qt?
• Will someone who has the current version of my tap installed then tries to install a package like homebrew/core/pushpin post-name-change correctly install the Qt5 dependency?
• Will formulae in other taps that depend on cartr/qt4/qt (example: cp4k/hello-world-2/hello-world-2 need to update to reflect this name change? Is there a way to ensure they still work, even if they don't update?

I don't know very much about Homebrew's internals, and I don't have easy access to clean Macs to test these scenarios for myself. Renaming a Formula appears to suggest that adding an entry in formula_renames.json is all I'd need to do; is this true in our case?

@MikeMcQuaid Also, is the new incoming versioning scheme you mention documented somewhere? I couldn't find anything in https://github.com/Homebrew/brew/tree/master/docs, and I'm curious what I should name packages like pyside that are specific to Qt4, don't have 5 in their version number, and could hypothetically receive a Qt5 version in the future.

[MikeMcQuaid]

If Homebrew naively tried to upgrade from the old qt to the new qt, for example, it would switch from Qt4 to Qt5 and stuff would break.

Homebrew will be doing this and this is intentional as we no longer support Qt4. This is no different to any other library in which we do a major version upgrade.

Will external software that depends on Homebrew-installed Qt4 still build correctly and not try to link against homebrew/core/qt?

That software will be broken regardless now that it's been removed and no officially supported migration has been provided.

Will someone who has the current version of my tap installed then tries to install a package like homebrew/core/pushpin post-name-change correctly install the Qt5 dependency?

Yes.

Will formulae in other taps that depend on cartr/qt4/qt (example: cp4k/hello-world-2/hello-world-2 need to update to reflect this name change? Is there a way to ensure they still work, even if they don't update?

Provided you use formula_renames.json they will be migrated happily from the old name but the formula should be updated medium-term.

Renaming a Formula appears to suggest that adding an entry in formula_renames.json is all I'd need to do; is this true in our case?

Yes.

@MikeMcQuaid Also, is the new incoming versioning scheme you mention documented somewhere?

Not yet, sorry. This work is still ongoing and I'm going to document all this stuff when it's done and properly announced.

I'm curious what I should name packages like pyside that are specific to Qt4, don't have 5 in their version number, and could hypothetically receive a Qt5 version in the future.

YAGNI 😉. Name it pyside.

[cartr]

I've made a Pull Request with the name changes. Once I get everything built and tested (should take a couple days at most, I'd just like to ensure the packages still actually work), I'll merge it and we should be squared away.

Regarding the new names, I ended up going with qt4 and pyqt4 for now to match how homebrew/versions does it. Once the new versioning scheme gets fully announced and documented and stuff, I'll look into renaming the packages again to match the new best practices.

@MikeMcQuaid Thank you for your help! It's really cool of you to give me a hand with my tap even though Homebrew doesn't official support Qt4 anymore.

[MikeMcQuaid]

Note that the homebrew/versions format has already been altered for the packages that have already been migrated into homebrew/core; that may be entirely completed before your PR is merged (depending on how much other stuff ends up on my plate in the coming weeks). My goal is to have all of the rest migrated very shortly. I'd strongly advise against renaming twice as you're going to cause more work for your users. Obviously in the end it's up to you, though.

[notduncansmith]

Hey guys, I think I may have gotten caught up in the weird transitional state related to this issue.

I'm trying to install Poppler through Homebrew and it depends on qt, which Hombrew insists refers to Qt 5.

I've tapped and pinned this repo and run brew install qt which appears to successfully install this version (4.8.7), but every time I try to brew install poppler --with-qt it starts installing qt.

Here is the output from brew info qt, brew info poppler, and brew install poppler --with-qt:

brew info qt
cartr/qt4/qt: stable 4.8.7 (bottled), HEAD
Cross-platform application and UI framework
https://www.qt.io/
/usr/local/Cellar/qt/4.8.7_3 (2,720 files, 109.4M) *
  Poured from bottle on 2017-01-03 at 15:33:35
From: https://github.com/cartr/homebrew-qt4/blob/master/qt.rb
==> Dependencies
Required: openssl ✔
Optional: dbus ✘, mysql ✘, postgresql ✘
==> Requirements
Build: git ✔
==> Options
--with-dbus
	Build with dbus support
--with-docs
	Build documentation
--with-mysql
	Build with mysql support
--with-postgresql
	Build with postgresql support
--with-qt3support
	Build with deprecated Qt3Support module support
--without-webkit
	Build without QtWebKit module
--HEAD
	Install HEAD version
==> Caveats
We agreed to the Qt opensource license for you.
If this is unacceptable you should uninstall.

Qt Designer no longer picks up changes to the QT_PLUGIN_PATH environment
variable as it was tweaked to search for plug-ins provided by formulae in
  /usr/local/lib/qt4/plugins

Phonon is not supported on macOS Sierra or with Xcode 8.

.app bundles were installed.
Run `brew linkapps qt` to symlink these to /Applications.

brew info poppler
poppler: stable 0.47.0 (bottled)
PDF rendering library (based on the xpdf-3.0 code base)
https://poppler.freedesktop.org/
Conflicts with: pdftohtml
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/poppler.rb
==> Dependencies
Build: pkg-config ✔
Required: cairo ✔, fontconfig ✔, freetype ✔, gettext ✔, glib ✔, gobject-introspection ✔, jpeg ✔, libpng ✔, libtiff ✔, openjpeg ✔
Optional: qt ✘, qt5 ✘, little-cms2 ✔
==> Options
--with-little-cms2
	Use color management system
--with-qt
	Build Qt backend
--with-qt5
	Build Qt5 backend

brew install poppler --with-qt
==> Installing dependencies for poppler: qt
==> Installing poppler dependency: qt
==> Downloading https://homebrew.bintray.com/bottles/qt5-5.7.1_1.sierra.bottle.tar.gz
^C^C^C^C
(┛◉Д◉)┛彡┻━┻

Apologies if there's an obvious solution here, I'm not a very advanced Homebrew user. Thanks for all your hard work guys!

[cartr]

@notduncansmith The issue here seems to be that the Poppler formula in Homebrew/core no longer supports building with the Qt4 backend, and the options have been re-wired to give you Qt5 instead.

I've never used Poppler, so I don't know how important the choice of backend is. If it doesn't really matter, you could try brew install qt5 to install Qt5 in a way that doesn't conflict with this tap, then install Poppler normally. Otherwise I would appreciate it if you filed a separate issue so we can get Poppler added to this repository.

[RandomDSdevel]

I think we just need to get rid of Poppler's old --with-qt option, which referenced Qt 4 when the qt4 formula still had the qt alias associated with it, and leave the formula with only a --with-qt5 option. IIRC, the two options gave Poppler conflicting configure options in the first place, anyway.

[bblacey]

Is there a targeted timeline for to complete the rename PR? I am asking to make informed decisions when planning FreeCAD QT dependencies.

[cartr]

@bblacey The current plan is to get the patch merged as soon as Homebrew/brew#1770 gets fixed, but I'm unsure how long that'll take.