| Summary: | >=app-admin/setools-4.0.0: suspicious dependency on dev-qt/qtchooser | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Davide Pesavento (RETIRED) <pesa> |
| Component: | SELinux | Assignee: | Sven Vermeulen (RETIRED) <swift> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | qt, selinux |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Davide Pesavento (RETIRED)
2016-05-17 16:49:09 UTC
The dep is not needed. There was a call towards qcollectiongenerator and was associated with qtchooser. But the dependency towards PyQt5 is sufficient (and needed). setools is bumped to 4.0.1 (upstream made a new release recently with a small change in it regarding icons) with this change in place. I also updated the dependency towards libsepol to libsepol-2.5 as this is needed for setools-4. Currently, setools-4 is still without keywords as it is not fully compatible with setools-3 (upstream decision) and we will need to wait until the depending packages are updated with the setools-4 specific calls in them. (In reply to Sven Vermeulen from comment #1) > The dep is not needed. There was a call towards qcollectiongenerator and was > associated with qtchooser. But the dependency towards PyQt5 is sufficient > (and needed). qtchooser is just a "dispatcher" between qt4 and qt5, it should never be depended upon. The actual qcollectiongenerator binary is installed by dev-qt/qthelp. That would be the correct dependency. Btw, note that if the package build system calls /usr/bin/qcollectiongenerator directly, that's a bug because there's no guarantee on which version will be invoked. In this case you can add a workaround to the ebuild by exporting QT_SELECT=[4|5], but the bug should be reported upstream. > setools is bumped to 4.0.1 (upstream made a new release recently with a > small change in it regarding icons) with this change in place. I also > updated the dependency towards libsepol to libsepol-2.5 as this is needed > for setools-4. > > Currently, setools-4 is still without keywords as it is not fully compatible > with setools-3 (upstream decision) and we will need to wait until the > depending packages are updated with the setools-4 specific calls in them. Thanks. Would you mind updating -9999 as well? (In reply to Davide Pesavento from comment #2) > (In reply to Sven Vermeulen from comment #1) > > The dep is not needed. There was a call towards qcollectiongenerator and was > > associated with qtchooser. But the dependency towards PyQt5 is sufficient > > (and needed). > > qtchooser is just a "dispatcher" between qt4 and qt5, it should never be > depended upon. The actual qcollectiongenerator binary is installed by > dev-qt/qthelp. That would be the correct dependency. > > Btw, note that if the package build system calls > /usr/bin/qcollectiongenerator directly, that's a bug because there's no > guarantee on which version will be invoked. In this case you can add a > workaround to the ebuild by exporting QT_SELECT=[4|5], but the bug should be > reported upstream. It *can* call qcollectiongenerator to re-generate the help files. They have already been generated tho in the repo so the dep is only needed if we want to re-generate which we dont actually do. > > setools is bumped to 4.0.1 (upstream made a new release recently with a > > small change in it regarding icons) with this change in place. I also > > updated the dependency towards libsepol to libsepol-2.5 as this is needed > > for setools-4. > > > > Currently, setools-4 is still without keywords as it is not fully compatible > > with setools-3 (upstream decision) and we will need to wait until the > > depending packages are updated with the setools-4 specific calls in them. > > Thanks. Would you mind updating -9999 as well? I will double check the QT_SELECT stuff and update -9999. I dont think it requires regenerating either but will confirm. If setup.py exports QT_SELECT itself is that correct? or should the build system be directly calling a different binary? (In reply to Jason Zaman from comment #3) > I will double check the QT_SELECT stuff and update -9999. I dont think it > requires regenerating either but will confirm. If setup.py exports QT_SELECT > itself is that correct? or should the build system be directly calling a > different binary? The build system must not use QT_SELECT, that's just a hack/workaround. It should call the actual binary using its (version-specific) full path. I think you can use `$$[QT_INSTALL_BINS]/qcollectiongenerator` in a qmake-based build system. 9999 was fixed in commit 0dca6e6accc0f97f70dd4d8a364e39664ca49ea5 |