Description of problem: I need to run a 32-bit application that is written with Qt4 and connects to PostgreSQL database on my 64-bit host system. I have successfully installed all required 32-bit libs including Qt4 ones but I'm unable to install 32-bit qt4-database-plugin-pgsql package as it has conflicting name with 64-bit counterpart. The same problem occurs with other SQL plugins for Qt4 (MySQL, sqlite, TDS). This bug report is applicable to both Mageia 2 and 3 and probably to cauldron. Version-Release number of selected component (if applicable): Qt4 4.8.x How reproducible: always Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Assignee: bugsquad => nicolas.lecureuil
please give the error message
(In reply to Nicolas Lécureuil from comment #1) > please give the error message What error message you mean? There is no error message. The 32-bit package is just unavailable if 64-bit one is already installed. It is not listed in rpmdrake. urpmi says it is already installed (even though its architecture is different). And manual installation with rpm -Uvh command doesn't work because rpm doesn't support installing two packages with the same name but different arch.
(In reply to Oleg Bosis from comment #2) > And manual installation with rpm -Uvh command doesn't work > because rpm doesn't support installing two packages with the same name but > different arch. Yes I wouldn't expect rpm -Uvh to work in that context, but what about rpm -ivh ? That will let two packages of the name *and* architecture be installed as long as they're different versions, so maybe it'll allow two packages to be installed with the same name and version but different architectures (I'm not sure). If both packages had the same files, this certainly wouldn't work because of a file conflict, but it looks like the files in question are stored in %{_libdir}/qt4 which is different on each arch (/usr/lib vs. /usr/lib64) so it's worth a shot.
Yes, 'rpm -ivh' do work. But anyway manual downloading a package from repository and installing it with direct call to rpm is not a proper solution. What about the package dependencies? The packages should be installable using standard high-level package management tools (i.e. rpmdrake in GUI and urpmi in console). And this in turn requires 32-bit and 64-bit packages have different names. Qt plugins are libs by their nature so I think their package names should follow library packaging policies.
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD
Status: RESOLVED => REOPENEDVersion: 2 => 3Resolution: OLD => (none)
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: REOPENED => RESOLVEDResolution: (none) => OLD
The bug is still here so reopened with version 4. Should I change the version to cauldron to avoid closing unfixed bugs due to 'eol' reason?
Status: RESOLVED => REOPENEDVersion: 3 => 4Resolution: OLD => (none)
(In reply to Oleg Bosis from comment #8) > The bug is still here so reopened with version 4. Should I change the > version to cauldron to avoid closing unfixed bugs due to 'eol' reason? If you know the bug exists in Cauldron (or 5 beta 3) too, yes, then please set version to cauldron and add "MGA4TOO" on the whiteboard.
CC: (none) => marja11
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
I don't see any change in package names for Qt plugins for both Qt4 and Qt5 so I do reopen this bug against cauldron and rename it to include Qt5 too.
Status: RESOLVED => REOPENEDVersion: 4 => CauldronResolution: OLD => (none)Summary: Unable to install 32-bit Qt4 SQL plugins on 64-bit host => Unable to install 32-bit Qt4 and Qt5 SQL plugins on 64-bit hostWhiteboard: (none) => MGA5TOO
please provide the urpmi error message.
As I have already written previously that the problem is that both 32 and 64 bit packages for qt sql plugins have the same name and urpmi just tells that the package already installed and rpmdrake do not display 32-bit version when 64-bit version is already installed. So there could be two ways to solve: 1. Just change please the names for qt plugin packages the same way as they are in some other distros (ubuntu for example), i.e.: libqt4-database-plugin-mysql/lib64qt4-database-plugin-mysql and the same way for all other qt sql plugins for both qt4 and qt5. BTW this naming should fully satisfy packaging policy as this packages only contain *.so* files that are libraries by their nature. or 2. Add some option to urpmi to explicitly provide architecture of a package that have to be installed. And also fix rpmdrake making it properly display 32-bit packages even if the 64-bit package with the same name is already installed. BTW 2: providing fully qualified name do not properly work: [olelukoie@asus-nb ~]$ LC_ALL=C sudo urpmi qt4-database-plugin-pgsql-4.8.6-9.mga5.x86_64 Package qt4-database-plugin-pgsql-4.8.6-9.mga5.x86_64 is already installed [olelukoie@asus-nb ~]$ LC_ALL=C sudo urpmi qt4-database-plugin-pgsql-4.8.6-9.mga5.i586 [olelukoie@asus-nb ~]$ This shows that the 32-bit package is just silently ignored.
(In reply to Nicolas Lécureuil from comment #13) > please provide the urpmi error message. Also see your own comment 1 and my reply in comment 2
Please try next Qt4 from Cauldron.
Please try next Qt5 from Cauldron too.
(In reply to Nicolas Lécureuil from comment #17) > Please try next Qt5 from Cauldron too. I do not have cauldron installations right now so I would be able to create it and test only at weekend. But I've tried to build a backport of teh new qtbase5 and noticed that the plugin packages do not update automatically. I had to install every new plugin package manually and then I've seen a warning that it will remove old plugin package to install the new one. Probably wrong/missing Obsoletes? Currently there are obsoletes of "qt5-database-plugin-*" packages but the old ones are "qtbase5-database-plugin-*".
Assignee: mageia => kde
closing as fixed .
Status: REOPENED => RESOLVEDCC: (none) => mageiaResolution: (none) => FIXED