Bug 1063607 - glibc: Complete MoveToUsr transition
Summary: glibc: Complete MoveToUsr transition
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: glibc team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1538359 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-11 06:32 UTC by cornel panceac
Modified: 2020-12-21 17:12 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-11 07:24:16 UTC
Type: Bug


Attachments (Terms of Use)
yum is not solving dependencies (8.68 KB, text/plain)
2014-02-11 06:32 UTC, cornel panceac
no flags Details
another example of yum being unable to solve depedencies, again glibc related. (42.90 KB, text/plain)
2014-02-11 06:50 UTC, cornel panceac
no flags Details
yum log, not verbose (1.64 KB, text/plain)
2014-02-11 18:11 UTC, cornel panceac
no flags Details
typescript (1.95 KB, text/plain)
2015-03-01 09:59 UTC, Peter H. Jones
no flags Details

Description cornel panceac 2014-02-11 06:32:06 UTC
Created attachment 861683 [details]
yum is not solving dependencies

Description of problem:
trying to downgrade glibc, yum does not do it because other glibc* packages require a newer version of glibc.

downgrading all glibc* packages however, works.


Version-Release number of selected component (if applicable):
$ rpm -q yum
yum-3.4.3-132.fc20.noarch


How reproducible:
always


Steps to Reproduce:
1.
2.
3.

Actual results:
dependencies are not solved (yum is not proposing to downgrade the required packages)

Expected results:
yum proposes to downgrade all packages required for downgrading glibc

Additional info:

Comment 1 cornel panceac 2014-02-11 06:50:13 UTC
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.

Comment 2 Jan Zeleny 2014-02-11 07:24:16 UTC
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.

Comment 3 cornel panceac 2014-02-11 18:11:28 UTC
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?

Comment 4 Jan Zeleny 2014-02-13 15:41:30 UTC
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".

Comment 5 cornel panceac 2014-02-13 15:51:18 UTC
well i understand your point but, after upgrading glibc, i can safely reinstall same "broken" libdvdcss2, and all the dependencies are satisfied.

Comment 6 cornel panceac 2014-08-25 11:38:37 UTC
this problem is still present. latest example: yum upgrade fails because --skip-broken skips all packages. 
upgrading only subsets, works, though.

Comment 7 cornel panceac 2014-08-26 09:12:01 UTC
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 .

Comment 8 Ian Pilcher 2014-09-09 16:45:16 UTC
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.

Comment 9 Ian Pilcher 2014-09-09 17:13:30 UTC
(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.   :-)

Comment 10 Peter H. Jones 2015-03-01 09:59:27 UTC
Created attachment 996739 [details]
typescript

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

Comment 11 Maciej Mrozowski 2015-03-13 10:57:10 UTC
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

Comment 12 Carlos O'Donell 2015-03-13 12:56:02 UTC
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."

Comment 13 Radek Holy 2015-03-13 13:13:00 UTC
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 .

Comment 14 Ian Pilcher 2015-03-13 19:18:21 UTC
(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?

Comment 15 Carlos O'Donell 2015-03-13 19:50:15 UTC
(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.

Comment 16 Peter H. Jones 2015-03-13 21:43:44 UTC
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.

Comment 17 Jan Kurik 2015-07-15 14:43:08 UTC
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

Comment 18 Fedora End Of Life 2016-11-24 11:06:39 UTC
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.

Comment 19 Fedora End Of Life 2017-02-28 09:36:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 20 Carlos O'Donell 2018-01-24 22:21:31 UTC
*** Bug 1538359 has been marked as a duplicate of this bug. ***

Comment 21 Fedora End Of Life 2018-02-20 15:22:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 22 Martin Kutlak 2018-03-26 14:37:49 UTC
Is there any progress with this bugzilla?

Comment 23 Carlos O'Donell 2018-03-26 17:30:51 UTC
(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.

Comment 24 Jan Kurik 2018-08-14 10:24:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 25 Ben Cotton 2019-08-13 16:47:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.


Note You need to log in before you can comment on or make changes to this bug.