Bug 1030768
Summary: | hamlib.x86_64 conflicts with hamlib.i686 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Asif Ali Rizvan <fast.rizwaan> | ||||
Component: | hamlib | Assignee: | Jaroslav Škarvada <jskarvad> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | admiller, bobjensen, ffesti, firas.alkafri, hobbes1069, jskarvad, jzeleny, lucilanga, packaging-team-maint, pmatilai, randyn3lrx, sindrepb | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-07-01 13:36:13 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Asif Ali Rizvan
2013-11-15 05:25:47 UTC
File conflicts are packaging bugs. In this case there a are two separate sources of problems: 1) hamlib is using the old-style dependency filtering system (http://fedoraproject.org/wiki/EPEL:Packaging_Autoprovides_and_Requires_Filtering) which is explicitly not allowed for packages installing binaries in path, because the old filtering system has side-effects for multilib installations. It should be updated to use the rpm built-in filtering which has no such limitations: http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering. Also it often makes sense to split the libraries and binaries into separate packages which also avoids unnecessary multilib conflicts. 2) The .html file conflicts are plain old content conflicts, eg doxygen generated documentation often contains differences between architectures. Often the best solution is to split the (API) documentation into a separate, noarch sub-package. I'm looking into this but I'm not sure if I have ACL access to all branches. Additionally, the python sub-package is incorrectly installing into python_sitelib even though it's providing a arch specific library, _Hamlib.so. I think I have addressed the problems including installing the python bindings to the correct location but in order to completely solve the multi-lib problem don't I have to split the binaries into a separate package? I switched to the recent dependency filtering system in the rawhide, which should resolve most of the conflicts. So far there is only python object files multilib conflict remaining. This shouldn't happen as the object files should be arch independent. I am going to take deeper look on it. Got it, there is timestamp difference in the .pyc/.pyo files because the source .py is swig generated and has different modification time. Nevertheless this should go away by fixing the python installation path. Created attachment 911816 [details]
Proposed fix
I am proposing the following patch to fix the python dir.
I am going to push the patch from comment 6 to rawhide and backport the new filtering system support to f20. I will not backport the python files location fix to f20, because we probably shoudn't do this during stable release. If the new python files location breaks anything for you, feel free to revert it in rawhide. Also I am going to send this patch upstream. Well, I am not backporting anything. I am moving this bug to rawhide and fixing it all there. I think this is the best solution. If you really need to backport the fixes, please reopen this bug or comment. (In reply to Jaroslav Škarvada from comment #6) > Created attachment 911816 [details] > Proposed fix > > I am proposing the following patch to fix the python dir. Patch sent upstream. |