Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=895149 --- Comment #7 from Kevin Kofler <kevin@xxxxxxxxxxxxxxxx> --- > First off, for better or worse, fedora's policies do not require justification > for a package review. So, arguing against a package in it's review on this > basis, is... pointless. Packaging a package that serves no purpose is what is pointless. > Now, *if* I were to make a case... :) I would say that qtchooser is the tool > that Qt upstream came up with to standardize a way for developers to use/switch > Qt development environments. Other distros are supporting it, and I think > fedora should too. I argue not supporting qtchooser would make fedora look bad > and hurt it's reputation. And I argue that "supporting" this half-assed solution in an even more half-assed way (your "compromise" which "fixes" the blocking issues by just requiring a manual step to enable qtchooser, which makes it even more pointless because the same method can be used to just choose Qt directly) is what will make Fedora look bad and hurt its reputation. We need instead to make a clear stand that qtchooser is NOT a suitable solution for the problem it is designed to solve and that a better solution needs to be standardized across distros. (And if the other distros refuse, that's their loss. Chances are at least RHEL will follow us. E.g., RHEL 6 ships my kdelibs parallel-devel setup unchanged.) > Second, I do agree that better solutions than qtchooser exist, and fedora's Qt > packaging already does does support (imo) better options, like manually > adjusting paths or using -qt4 and/or -qt5 postfix on related binaries as > mentioned. That's exactly why qtchooser is useless. > However, that does not preclude supporting *yet another option*. But it makes it pointless. > This latest packaging implementation is careful to minimize side-effects, is > not installed or used by default, and is strictly optional. And as a result, it solves no problem at all. > As for binary location, I personally don't care all that much > (/usr/lib/bikeshed anyone?). Strictly, our guidelines allow either, and I only > chose /usr/lib (similar to ccache) because I personally consider /usr/libexec > to be non-user-facing. I don't consider either option *wrong*. The fact that binaries are allowed in /usr/lib is an unfortunate loophole in our guidelines. This is clearly what libexec is for. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1fXqrgcDJC&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review