Description of problem: Running on Mageia-5A2 (64-bit, KDE) a recent update failed, apparently because an RPM for ooRexx is installed. (This does NOT occur on 32-bit Mageia-5A2.) Version-Release number of selected component (if applicable): urpmi-7.32-1.mga5.src.rpm How reproducible: Steps to Reproduce: 1. urpmi --auto-update 2. See failure messages: ---------------------- Installation failed: /sbin/service is needed by (installed) ooRexx-4.2.0-9940.opensuse1230.x86_64 libLLVM-3.5.so()(64bit) is needed by lib64gbm1-10.3.0-0.rc3.1.mga5.x86_64 hostname is needed by lib64cups2-1.7.5-5.mga5.x86_64 libLLVM-3.5.so()(64bit) is needed by lib64xatracker2-10.3.0-0.rc3.1.mga5.x86_64 libLLVM-3.5.so()(64bit) is needed by lib64mesaegl1-10.3.0-0.rc3.1.mga5.x86_64 libprotobuf-c.so.1()(64bit) is needed by lib64gadu3-1.12.0-2.mga5.x86_64 perl(Test::Deep) >= 0.110.0 is needed by perl-CGI-1:4.40.0-1.mga5.noarch kernel-desktop-3.17.0-0.rc4.1.mga5 is needed by virtualbox-kernel-3.17.0-desktop-0.rc4.1.mga5-4.3.14-4.mga5.x86_64 lib64cups2 >= 1.7.5-5.mga5 is needed by cups-common-1.7.5-5.mga5.x86_64 hostname is needed by cups-common-1.7.5-5.mga5.x86_64 libSDL2-2.0.so.0()(64bit) is needed by openal-1.16.0-1.mga5.x86_64 libSDL_sound-1.0.so.1()(64bit) is needed by openal-1.16.0-1.mga5.x86_64 hostname is needed by cups-1.7.5-5.mga5.x86_64 kernel-desktop-3.17.0-0.rc4.1.mga5 is needed by kernel-desktop-latest-3.17.0-0.rc4.1.mga5.x86_64 kdelibs4-core >= 2:4.14.0-2.mga5 is needed by kdelibs4-handbooks-2:4.14.0-2.mga5.noarch hostname is needed by basesystem-minimal-1:2-18.mga5.x86_64 lib64devmapper-event1.02 >= 1.02.90 is needed by lib64lvm2app2.2-2.02.111-1.mga5.x86_64 gstreamer0.10-tools >= 0.10.36-8.mga5 is needed by libgstreamer0.10_0-0.10.36-8.mga5.i586 v4l-utils >= 1.4.0 is needed by libv4l0-1.4.0-1.mga5.i586 kernel-desktop-3.17.0-0.rc4.1.mga5 is needed by nvidia-current-kernel-3.17.0-desktop-0.rc4.1.mga5-340.32-3.mga5.nonfree.x86_64 hostname is needed by libcups2-1.7.5-5.mga5.i586 --------------------------------------- 3. Result: E.g. VirtualBox and kernel not updated. 4. Try: urpmi --auto-update --split-length=1 Result: Update successful! Just one failure report at end: "Installation failed: /sbin/service is needed by (installed) ooRexx-4.2.0-9940.opensuse1230.x86_64" (N.B. sbin/service *is* there, and ooRexx does work.) A comment elsewhere suggests the failure was because of the presence of a "non-mageia" RPM, but why should that mess up the update? I have Dropbox installed (another non-Mageia app) but that was not a problem.) Reproducible: Steps to Reproduce:
CC: (none) => maurice
The ooRexx package will need to be fixed, as a hard-coded file requires on /sbin/service will no longer work (the file is now /usr/sbin/service in the package).
Status: NEW => RESOLVEDCC: (none) => mageiaResolution: (none) => INVALID
> ...a hard-coded file requires on /sbin/service will no longer work (the file > is now /usr/sbin/service in the package). (1) Both files exist on the 64-bit Mageia-5A2 install, so why does urpmi object? (2) Why does urpmi take any notice of the installed ooRexx RPM? (The 32-bit Mageia-5A2 urpmi totally ignores it...) (3) I have been using ooRexx for many years; it's one of the non-Mga tools in my toolbox( which includes e.g. Dropbox), and urpmi has never complained. What has happened to cause urpmi to mess up a whole update because of an installed non-Mga RPM?
(In reply to Maurice Batey from comment #2) > > ...a hard-coded file requires on /sbin/service will no longer work (the file > > is now /usr/sbin/service in the package). > > (1) Both files exist on the 64-bit Mageia-5A2 install, so why does urpmi > object? Both files don't exist really. They are the same file, but perhaps now there is no provide. We had to add manual provides in the past to work around such changes, and I suspect I should just do the same here. I forget the package I had to tweak for this util-linux maybe... > (2) Why does urpmi take any notice of the installed ooRexx RPM? > (The 32-bit Mageia-5A2 urpmi totally ignores it...) > > (3) I have been using ooRexx for many years; it's one of the non-Mga tools > in my toolbox( which includes e.g. Dropbox), and urpmi has never complained. > What has happened to cause urpmi to mess up a whole update because of an > installed non-Mga RPM? It's likely because there is a Requires: in said RPM that is no longer satisfied. I'm sure it can be fixed easily enough and indeed should be resolved in -5.mga5.
Source RPM: urpmi-7.32-1.mga5.src.rpm => initscripts-9.55-4.mga5.src.rpm
Thank you, Colin! Glad to see it can be sorted out. In the meantime I shall just uninstall it before an update and then re-install. I just wish I could understand why urpmi takes any notice of the installed ooRexx RPM at all, as it is not an inherent part of Mageia-5A2, so the update will not contain any updates to it, and why the problem isn't there in the 32-bit Mageia-5A2 urpmi...)
(In reply to Maurice Batey from comment #4) > Thank you, Colin! Glad to see it can be sorted out. > In the meantime I shall just uninstall it before an update and then > re-install. Just wait for the new initscripts package to hit the mirrors and see if things are OK. If it still complains about a missing /sbin/service then there is still a problem somewhere. > I just wish I could understand why urpmi takes any notice of the installed > ooRexx RPM at all, as it is not an inherent part of Mageia-5A2, so the > update will not contain any updates to it, and why the problem isn't there > in the 32-bit Mageia-5A2 urpmi...) urpmi looks at the RPM database. In the past our initscripts "provided" (in a package metadata sense) "/sbin/service". Your third party RPM has a "Requires: /sbin/service". As our updated initscripts package no longer "provides" "/sbin/service" (instead providing "/usr/sbin/service" which is for all practical purposes the same and would work just as well), we either have to remove your thrid party RPM or no upgrade our initscripts. This is the dependency model that RPM needs to ensure all is well. Any package known by rpm will inherently be taken into consideration when urpmi is doing it's thing. It cannot ignore a dependency requirement just because the package is from a 3rd party source... that's not how deps works!
OIC. Although I have not had this problem with the ooRexx RPM before, I guess what has happened is that the latest version I've been installing recently has got a changed dependency (or the Mageia environnment has changed such that the ooRexx dependency should change). Thank you once again for your patience, Colin. Much appreciated...
(In reply to Maurice Batey from comment #6) > (or the Mageia environnment has changed such that the ooRexx dependency > should change). Yup, it's that one. No package in Mageia provided what ooRexx needed (due to a change in the Mageia initscripts package). I've now (hopefully) corrected that so that this external package should be OK. Fedora also manually provide /sbin/service so I guess this is a sufficiently common case for us to still maintain backwards compatibility for. > Thank you once again for your patience, Colin. Much appreciated... No problem!