Bug 1063607

Created attachment 861686 [details]
another example of yum being unable to solve depedencies, again glibc related.

I was trying to update the system. glibc could not be updated because libdvdcss2 apparently would not be satisfied by the new glibc. However, if i removed libdvdcss2, then updated glibc, after, i was able to reinstall libdvdcss2 just fine.

The original report is not a bug, downgrading is not default behavior of yum, hence you need to specify all packages that you want to downgrade manually. As for the second, seems to be rather packaging bug than a bug of yum. If you could send me the update log without -v, I might be able to verify that, this verbose log is not lucid for me.

Created attachment 861927 [details]
yum log, not verbose

Here's the not verbose log (from an x86_64 machine, this time.)

Regarding the original issue, can we add the depsolving feature for yum downgrade?

Ok, that's better. Comparing the simple log and the verbose log, it seems that libdvdcss2-1.2.13-7.fc20.x86_64 depends on something that the glibc doesn't provide (/usr/sbin/ldconfig perhaps), so the update is obviously blocked. Check the source of your libdvdcss2 package and contact the maintainer to take a look at this.

Workaround for this problem is to uninstall the libdvdcss2 package and perform the update.

In any case, I'm going to stick with "not a bug".

well i understand your point but, after upgrading glibc, i can safely reinstall same "broken" libdvdcss2, and all the dependencies are satisfied.

this problem is still present. latest example: yum upgrade fails because --skip-broken skips all packages. 
upgrading only subsets, works, though.

eventually, i was able to manually install all packages except the glibc\* packages (which again have the above mentioned problem with libdvdcss2). still, i believe the packages that i was able to install manually should have been automaticallyu installed bby yum --skip-broken .

I'm seeing issues with /usr/sbin/ldconfig on both CentOS 7 and Fedora 20:

--> Processing Dependency: /usr/sbin/ldconfig for package: libcip-0.1.1.4-1.el7.centos.x86_64
--> Finished Dependency Resolution
Error: Package: libcip-0.1.1.4-1.el7.centos.x86_64 (@/libcip-0.1.1.4-1.el7.centos.x86_64)
           Requires: /usr/sbin/ldconfig
           Removing: glibc-2.17-55.el7.x86_64 (@anaconda)
               Not found
           Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates)
               Not found

(libcip is a package of my own creation that has a specific dependency on /usr/sbin/ldconfig.)

glibc obviously does provide /usr/sbin/ldconfig.  (In fact it's the real path to that file these days.)  But yum only seems to realize this is true for the installed version:

$ sudo yum provides /usr/sbin/ldconfig
Loaded plugins: langpacks, show-leaves
glibc-2.18-14.fc20.x86_64 : The GNU libc libraries
Repo        : @updates
Matched from:
Filename    : /usr/sbin/ldconfig

OTOH, it sees the /sbin/ldconfig "compatibility" path for all versions:

$ sudo yum provides /sbin/ldconfig
Loaded plugins: langpacks, show-leaves
glibc-2.18-11.fc20.i686 : The GNU libc libraries
Repo        : fedora
Matched from:
Filename    : /sbin/ldconfig



glibc-2.18-11.fc20.x86_64 : The GNU libc libraries
Repo        : fedora
Matched from:
Filename    : /sbin/ldconfig



glibc-2.18-14.fc20.i686 : The GNU libc libraries
Repo        : updates
Matched from:
Filename    : /sbin/ldconfig



glibc-2.18-14.fc20.x86_64 : The GNU libc libraries
Repo        : updates
Matched from:
Filename    : /sbin/ldconfig



glibc-2.18-14.fc20.x86_64 : The GNU libc libraries
Repo        : @updates
Matched from:
Filename    : /sbin/ldconfig

My guess is that whatever "special sauce" was put in to include /sbin/ldconfig in the yum metadata is causing /usr/sbin/ldconfig to not be included.

(In reply to Ian Pilcher from comment #8)
> My guess is that whatever "special sauce" was put in to include
> /sbin/ldconfig in the yum metadata is causing /usr/sbin/ldconfig to not be
> included.

After a bit more research ... there is no special sauce.  The glibc package is still putting ldconfig into /sbin.  (And rpmbuild is blissfully unaware that /sbin is actually a symlink to /usr/sbin.)

So if this is a bug at all, it's an issue with the glibc package.  Adding an explicit provides for /usr/sbin/ldconfig would seem like a nice thing to do for those of us foolish enough to look at the filesystem when writing our SPEC files.   :-)

Created attachment 996739 [details]
typescript

Still see this bug update glibc-2.18-16.fc20 .

The same problem on Fedora 21 wim dnf with some package that explicitly requires "/usr/sbin/ldconfig".
Perhaps requiring ldconfig with full path by package is a problem, still dnf incorrectly checks whether this particular (admittedly overly explicit) package dependency is met.

Also here, what is funny:
[mrozowsk@localhost ~]$ sudo dnf provides ldconfig
(...)
glibc-2.20-8.fc21.x86_64 : The GNU libc libraries
Repo        : @System
(...)

and even:
[mrozowsk@localhost ~]$ sudo dnf provides /sbin/ldconfig
(...)
glibc-2.20-8.fc21.x86_64 : The GNU libc libraries
Repo        : @System

but query for explicit valid full path:
[mrozowsk@localhost ~]$ sudo dnf provides /usr/sbin/ldconfig
Error: No Matches found

You can't depend on /usr/sbin/ldconfig, glibc does not provide it.

The GNU C Library package has not completed the MoveToUsr, and therefore still provides binaries at /sbin/ldconfig.

Why has glibc not completed MoveToUsr? Because it is an incredibly complicated move that requires significant backwards compatibiltiy to support, and has not been worked through yet. The last attempt resulted in a broken Rawhide as insufficient backwards-compatible provides were present.

Therefore until glibc complets the MoveToUsr this is not a bug, and packages should not depend on "/usr/sbin/ldconfig", but instead "/sbin/ldconfig."

Yes, I think that this is in alignment with Fedora guidelines https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=405928#Effect_of_the_UsrMove_Fedora_Feature .

(In reply to Carlos O'Donell from comment #12)
> Therefore until glibc complets the MoveToUsr this is not a bug, and packages
> should not depend on "/usr/sbin/ldconfig", but instead "/sbin/ldconfig."

Is there a reason that glibc can't add a virtual provide for /usr/sbin/ldconfig in the interim?

(In reply to Ian Pilcher from comment #14)
> (In reply to Carlos O'Donell from comment #12)
> > Therefore until glibc complets the MoveToUsr this is not a bug, and packages
> > should not depend on "/usr/sbin/ldconfig", but instead "/sbin/ldconfig."
> 
> Is there a reason that glibc can't add a virtual provide for
> /usr/sbin/ldconfig in the interim?

I would like to avoid an partial transition of a critical runtime package to MoveToUsr, either we are entirely using old paths, or we are entirely using new paths. I don't want to support anything in between.

The package in question, libdvdcss2 is not a fedora package, so I have nothing to say about it, and there is no maintainer to answer for it?

As pointed out by Radek Holy, it is within the Fedora Packaging guidelines, you need to be aware of packages that have not completed the transition to MoveToUsr.

Thus my official position as glibc maintainer is that this is not going to get a partial fix. When we fix it we will transition entirely to /usr as required by MoveToUsr (almost entirely, since ld.so can't be moved since it represents the ABI).

Retitling and assigning to Rawhide.

I suggest adding a temporary script to the Fedora RPM that would check for libdvdcss2 et al. and warn the user to remove and replace it (them) while glibc is being updated. The current failure mode is bewildering for those who have never encountered this bug and expect core packages updates like glibc's to just work. Fedora shouldn't have to take the rap for this, but if it doesn't, it's the users who have to.

I support the idea of making the move to usr an atomic operation.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

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 Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 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 Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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 Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

*** Bug 1538359 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Is there any progress with this bugzilla?

(In reply to Martin Kutlak from comment #22)
> Is there any progress with this bugzilla?

No. It's low on the priority list for now. If there is anything depending on this change, please notify us.

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Upstream glibc has moved to autoconf 2.71 which includes runstatedir support which means upstream can also be changed to use the right /run path, and this is also part of MoveToUsr transition.

Thus there are two remaining pieces here:
- Not breaking ABI with the loader path in PT_INTERP.
- Configuring with --runstatedir

I think we're ready to make progress on this :-)