Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=783825 --- Comment #30 from Orcan Ogetbil <oget.fedora@xxxxxxxxx> 2012-04-09 23:31:09 EDT --- Thanks for the explanation. Do you have any links for the discussions? Please correct me if I am wrong: If gtk and Qt are the only supported toolkits by suil, then the plugin will drag in the Qt and the host will drag in gtk, or vice versa. Since both gtk and Qt will be dragged in in either case, it does not matter if the toolkit dependencies of suil are filtered out or not. However the story changes if suil supports more than these 2 toolkits (which is not the case for the time being). On the other hand, my biggest concern was not the above scenario exactly. It is not uncommon that Qt updates come with ABI incompatibility. In such circumstances, the Fedora-KDE SIG works well-coordinated to rebuild all Qt dependant packages. If you filter out the Qt dependency from suil, they will not know about the existence of it. The suil maintainer (that will be you until you give it up) will need to follow all the ABI related changes in the underlying toolkit Qt and has to coordinate manually with the Qt updates at all times. A similar argument applies for gtk rebuilds (although admittedly I don't have much experinence with gtk), or any other toolkit that will be supported by suil in the future. Are you sure do you want to walk that road? Shall we ask this in the Fedora-packaging list perhaps? What is so bad about dragging in the toolkits (seriously)? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review