Bug 996747 - [RFE] Move all to /usr difficult for glibc without assistance from rpm.
[RFE] Move all to /usr difficult for glibc without assistance from rpm.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-13 17:06 EDT by Carlos O'Donell
Modified: 2013-08-20 03:24 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-20 03:24:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Carlos O'Donell 2013-08-13 17:06:27 EDT
Dear RPM team,

The core glibc package has never completed the `Move to /usr' transition. The glibc package and all subpackages still install files into /lib, /lib64, /sbin, and /bin.

The glibc team has recently cleaned up the glibc.spec file and we attempted a `Move to /usr' transition[1] in rawhide to see what problems might result.

We immediately had build failures:
http://kojipkgs.fedoraproject.org//work/tasks/2927/5812927/root.log
~~~
DEBUG util.py:264:  Error: Package: libcom_err-1.42.8-3.fc20.x86_64 (build)
DEBUG util.py:264:             Requires: /sbin/ldconfig
DEBUG util.py:264:  Error: Package: libxml2-2.9.1-2.fc20.x86_64 (build)
DEBUG util.py:264:             Requires: /sbin/ldconfig
DEBUG util.py:264:  Error: Package: audit-libs-2.3.2-1.fc20.x86_64 (build)
DEBUG util.py:264:             Requires: /sbin/ldconfig
DEBUG util.py:264:  Error: Package: libtasn1-3.3-2.fc20.x86_64 (build)
DEBUG util.py:264:             Requires: /sbin/ldconfig
DEBUG util.py:264:  Error: Package: libacl-2.2.52-3.fc20.x86_64 (build)
DEBUG util.py:264:             Requires: /sbin/ldconfig
DEBUG util.py:264:  Error: Package: rpm-build-libs-4.11.1-5.fc20.1.x86_64 (build)
DEBUG util.py:264:             Requires: /sbin/ldconfig
...
~~~

All of the package implicitly reuqire /sbin/ldconfig as part of the Requires generation by rpmbuild. This generated requirement means that glibc can't complete the move to /usr transition easily.

I see two possible ways forward:

(a) glibc explicitly lists `Provides: /sbin/ldconfig' for all files that all existing packages have requirements on.

(b) rpm provides an alias list of Provides to be used during the transitional period. Any `Requires: /sbin/foo' is checked against a `Provides: /sbin/foo' and `Provides: /usr/sbin/foo' (since the two are equivalent after the move).

I don't like the idea of (a) because glibc does not actually provide /sbin/ldconfig.

I like (b) because this is actually a transitional packaging issue that has to do with the fact that rpmbuild generates requires to the full path of the provided binary and that full path has changed. This is particularly problematic because /sbin/ldconfig as provided by glibc is depended upon by all shared libraries to be run in the post and post-un phases.

Comments?

Cheers,
Carlos.

P.S. Sorry for breaking rawhide.

[1] https://lists.fedoraproject.org/pipermail/glibc/2013-August/000015.html
Comment 1 Jan Zeleny 2013-08-15 08:55:45 EDT
(In reply to Carlos O'Donell from comment #0)
> Dear RPM team,
> 
> The core glibc package has never completed the `Move to /usr' transition.
> The glibc package and all subpackages still install files into /lib, /lib64,
> /sbin, and /bin.
> 
> The glibc team has recently cleaned up the glibc.spec file and we attempted
> a `Move to /usr' transition[1] in rawhide to see what problems might result.
> 
> We immediately had build failures:
> http://kojipkgs.fedoraproject.org//work/tasks/2927/5812927/root.log
> ~~~
> DEBUG util.py:264:  Error: Package: libcom_err-1.42.8-3.fc20.x86_64 (build)
> DEBUG util.py:264:             Requires: /sbin/ldconfig
> DEBUG util.py:264:  Error: Package: libxml2-2.9.1-2.fc20.x86_64 (build)
> DEBUG util.py:264:             Requires: /sbin/ldconfig
> DEBUG util.py:264:  Error: Package: audit-libs-2.3.2-1.fc20.x86_64 (build)
> DEBUG util.py:264:             Requires: /sbin/ldconfig
> DEBUG util.py:264:  Error: Package: libtasn1-3.3-2.fc20.x86_64 (build)
> DEBUG util.py:264:             Requires: /sbin/ldconfig
> DEBUG util.py:264:  Error: Package: libacl-2.2.52-3.fc20.x86_64 (build)
> DEBUG util.py:264:             Requires: /sbin/ldconfig
> DEBUG util.py:264:  Error: Package: rpm-build-libs-4.11.1-5.fc20.1.x86_64
> (build)
> DEBUG util.py:264:             Requires: /sbin/ldconfig
> ...
> ~~~
> 
> All of the package implicitly reuqire /sbin/ldconfig as part of the Requires
> generation by rpmbuild. This generated requirement means that glibc can't
> complete the move to /usr transition easily.
> 
> I see two possible ways forward:
> 
> (a) glibc explicitly lists `Provides: /sbin/ldconfig' for all files that all
> existing packages have requirements on.
> 
> (b) rpm provides an alias list of Provides to be used during the
> transitional period. Any `Requires: /sbin/foo' is checked against a
> `Provides: /sbin/foo' and `Provides: /usr/sbin/foo' (since the two are
> equivalent after the move).
> 
> I don't like the idea of (a) because glibc does not actually provide
> /sbin/ldconfig.
> 
> I like (b) because this is actually a transitional packaging issue that has
> to do with the fact that rpmbuild generates requires to the full path of the
> provided binary and that full path has changed. This is particularly
> problematic because /sbin/ldconfig as provided by glibc is depended upon by
> all shared libraries to be run in the post and post-un phases.
> 
> Comments?

How many files are we talking about here? I see that there are only two executables in the glibc package. The thing is that you don't consider the amount of work needed for both (a) and (b). My best estimate is that (b) is much more painful if we are talking just about these two binaries - we are talking about writing extra code vs. adding a few lines to spec file of one package. Or am I missing something?

Thanks
Jan
Comment 2 Carlos O'Donell 2013-08-15 18:27:39 EDT
(In reply to Jan Zeleny from comment #1)
> (In reply to Carlos O'Donell from comment #0)
> > I see two possible ways forward:
> > 
> > (a) glibc explicitly lists `Provides: /sbin/ldconfig' for all files that all
> > existing packages have requirements on.
> > 
> > (b) rpm provides an alias list of Provides to be used during the
> > transitional period. Any `Requires: /sbin/foo' is checked against a
> > `Provides: /sbin/foo' and `Provides: /usr/sbin/foo' (since the two are
> > equivalent after the move).
> > 
> > I don't like the idea of (a) because glibc does not actually provide
> > /sbin/ldconfig.
> > 
> > I like (b) because this is actually a transitional packaging issue that has
> > to do with the fact that rpmbuild generates requires to the full path of the
> > provided binary and that full path has changed. This is particularly
> > problematic because /sbin/ldconfig as provided by glibc is depended upon by
> > all shared libraries to be run in the post and post-un phases.
> > 
> > Comments?
> 
> How many files are we talking about here? I see that there are only two
> executables in the glibc package. The thing is that you don't consider the
> amount of work needed for both (a) and (b). My best estimate is that (b) is
> much more painful if we are talking just about these two binaries - we are
> talking about writing extra code vs. adding a few lines to spec file of one
> package. Or am I missing something?

I would expect that all of the shared libraries in glibc might have auto-generated depends upon them. That is 21 libraries (only counting base names e.g. /lib64/libc.so.6 not /lib64/libc-2.17.90.so).

We have ~250 loadable gconv modules that are normally only accessed by glibc internally, so I don't expect any dependencies there. If RPM generated a dependency for gconv modules then the list of provides is much larger.

Have no other core packages run into the same problem? I would have expected such a workaround would be required for RPM for *all* of the other shared libraries that are being moved? Is the transition handled by brute force rebuilding and regenerating the dependencies? Why can't we just handle the glibc transition through the same process? That is to say  can we put in temporary provides, run a full rebuild of fedora for the next release, and end up in a state where we can remove the temporary provides? Do the temporary provides have to stay forever?

Jan, I appreciate you taking the time to think this through with me.
Comment 3 Panu Matilainen 2013-08-16 01:26:46 EDT
I sense a fair amount of confusion here.

Auto-generated shared library dependencies are on the soname (or basename if soname doesn't exist), not absolute path, and moving them around doesn't cause any disruption to dependencies. Generally only executables have absolute path requires on them, such as /sbin/ldconfig from eg "%post -p /sbin/ldconfig" (or manually added requires)

Literally, the only manual provide you should have to add for /usrmove is "Provides: /sbin/ldconfig" in the glibc main package. Or just leave glibc be as it is and never mind the mess that /usrmove is, which is what I'd actually recommend. For rpm, a manually added provide is not at all the same as an implicitly provided "physical file" at that location and turning /sbin/ldconfig into a virtual provide actually has some potential of breaking things on multilib installations.
Comment 4 Panu Matilainen 2013-08-16 01:30:00 EDT
...or just move all the shared libraries to /usr but the executables (notably /sbin/ldconfig) alone. That should work without any extra trouble to anybody.
Comment 5 Carlos O'Donell 2013-08-16 10:59:38 EDT
(In reply to Panu Matilainen from comment #3)
> I sense a fair amount of confusion here.
> 
> Auto-generated shared library dependencies are on the soname (or basename if
> soname doesn't exist), not absolute path, and moving them around doesn't
> cause any disruption to dependencies. Generally only executables have
> absolute path requires on them, such as /sbin/ldconfig from eg "%post -p
> /sbin/ldconfig" (or manually added requires)

Excellent. I fully admit I'm not a packaging expert when it comes to RPMs and filling this issue is part-and-parcel with determining exactly where we stand what should be considered.

So what happens with explicit depends on shared libraries?

Say for example in gcc we have:
~~~
# Ensure glibc{,-devel} is installed for both multilib arches
BuildRequires: /lib/libc.so.6 /usr/lib/libc.so /lib64/libc.so.6 /usr/lib64/libc.so
~~~

After MoveToUsr we won't provide /lib/libc.so.6 or /lib64/libc.so.6.

gcc does already BuildRequires glibc-devel, but it needs both the i686 and x86_64 versions because it builds a multiarch compiler. I see no easy way to express with BuildRequires that the package needs both variants without explicitly requesting the shared libraries provided by both glibc-devels?

Is there a way to express this multiarch BuildRequires?

What should we do here?

Add support for rpm to express `BuildRequires: glibc-devel.i686 >= X.Y.Z'?

Then remove the explicit library dependencies?

I would rather not have to express Provides on all the glibc libraries just because packages used that as a workaround to having both 32-bit and 64-bit versions of a particular library.

> Literally, the only manual provide you should have to add for /usrmove is
> "Provides: /sbin/ldconfig" in the glibc main package. Or just leave glibc be
> as it is and never mind the mess that /usrmove is, which is what I'd
> actually recommend. For rpm, a manually added provide is not at all the same
> as an implicitly provided "physical file" at that location and turning
> /sbin/ldconfig into a virtual provide actually has some potential of
> breaking things on multilib installations.

What is your definition of a multilib[1] installation? I assume you are talking about a system with 32-bit and 64-bit runtimes in different directories?

What problems do you see?

Note:
[1] Please keep in mind that `multilib' means something different to tools people, the term originating in gcc to talk about multiple runtime builds for different ISAs under the same compiler (and their structure is rather rigid). Historically the term seems to have been adopted by distributions to mean a single distribution supporting 32-bit and 64-bit runtimes for a given architecture e.g. x86/x86_64 etc.
Comment 6 Panu Matilainen 2013-08-19 04:29:43 EDT
(In reply to Carlos O'Donell from comment #5)
> 
> So what happens with explicit depends on shared libraries?
> 
> Say for example in gcc we have:
> ~~~
> # Ensure glibc{,-devel} is installed for both multilib arches
> BuildRequires: /lib/libc.so.6 /usr/lib/libc.so /lib64/libc.so.6
> /usr/lib64/libc.so
> ~~~

For runtime dependencies there's no need to use file dependencies to shared libraries as the generated dependencies are different between 32/64bit versions. BuildRequires on the unversioned library symlinks paths packaged in -devel are ... different, but also highly unusual.

> 
> After MoveToUsr we won't provide /lib/libc.so.6 or /lib64/libc.so.6.
> 
> gcc does already BuildRequires glibc-devel, but it needs both the i686 and
> x86_64 versions because it builds a multiarch compiler. I see no easy way to
> express with BuildRequires that the package needs both variants without
> explicitly requesting the shared libraries provided by both glibc-devels?
> 
> Is there a way to express this multiarch BuildRequires?
> 
> What should we do here?
> 
> Add support for rpm to express `BuildRequires: glibc-devel.i686 >= X.Y.Z'?
> 
> Then remove the explicit library dependencies?
> 
> I would rather not have to express Provides on all the glibc libraries just
> because packages used that as a workaround to having both 32-bit and 64-bit
> versions of a particular library.

See http://rpm.org/wiki/PackagerDocs/ArchDependencies. The gcc case could be handled with something like:

%ifarch %{multilib_64_archs} sparcv9 ppc
# Ensure glibc{,-devel} is installed for both multilib arches
BuildRequires: glibc-devel(%{__isa_name}-32)
BuildRequires: glibc-devel(%{__isa_name}-64)
%endif

> 
> > Literally, the only manual provide you should have to add for /usrmove is
> > "Provides: /sbin/ldconfig" in the glibc main package. Or just leave glibc be
> > as it is and never mind the mess that /usrmove is, which is what I'd
> > actually recommend. For rpm, a manually added provide is not at all the same
> > as an implicitly provided "physical file" at that location and turning
> > /sbin/ldconfig into a virtual provide actually has some potential of
> > breaking things on multilib installations.
> 
> What is your definition of a multilib[1] installation? I assume you are
> talking about a system with 32-bit and 64-bit runtimes in different
> directories?
> 
> What problems do you see?

Rpm tracks file presence in ways that cant be done with virtual provides. For example:

[pmatilai@localhost ~]$ rpm -q glibc
glibc-2.17-11.fc19.x86_64
glibc-2.17-11.fc19.i686
[pmatilai@localhost ~]$ rpm -qf /sbin/ldconfig 
glibc-2.17-11.fc19.x86_64
[pmatilai@localhost ~]$ 

glibc.i686 package contains /sbin/ldconfig too, but on x86_64 system that file doesn't actually get installed, its "shadowed" by the one from x86_64. As rpm remembers this, the installed glibc.i686 doesn't provide /sbin/ldconfig at all, with virtually provided /sbin/ldconfig such tricks stop working which can affect installation ordering, dependency resolution etc.

This probably wont make much of a difference with glibc as anything depending on /sbin/ldconfig will always have other dependencies to glibc too, but the point is that virtually provided files are not at all equal to implicitly provided actual files in a package.

> Note:
> [1] Please keep in mind that `multilib' means something different to tools
> people, the term originating in gcc to talk about multiple runtime builds
> for different ISAs under the same compiler (and their structure is rather
> rigid). Historically the term seems to have been adopted by distributions to
> mean a single distribution supporting 32-bit and 64-bit runtimes for a given
> architecture e.g. x86/x86_64 etc.

Yeah, I know (but keep forgetting :) multilib means different things to different people. In rpm context I use it rather loosely to mean an installation with mixed 32/64bit packages.
Comment 7 Carlos O'Donell 2013-08-20 02:37:27 EDT
(In reply to Panu Matilainen from comment #6)
> (In reply to Carlos O'Donell from comment #5)
> > 
> > So what happens with explicit depends on shared libraries?
> > 
> > Say for example in gcc we have:
> > ~~~
> > # Ensure glibc{,-devel} is installed for both multilib arches
> > BuildRequires: /lib/libc.so.6 /usr/lib/libc.so /lib64/libc.so.6
> > /usr/lib64/libc.so
> > ~~~
> 
> For runtime dependencies there's no need to use file dependencies to shared
> libraries as the generated dependencies are different between 32/64bit
> versions. BuildRequires on the unversioned library symlinks paths packaged
> in -devel are ... different, but also highly unusual.

OK.

> > I would rather not have to express Provides on all the glibc libraries just
> > because packages used that as a workaround to having both 32-bit and 64-bit
> > versions of a particular library.
> 
> See http://rpm.org/wiki/PackagerDocs/ArchDependencies. The gcc case could be
> handled with something like:
> 
> %ifarch %{multilib_64_archs} sparcv9 ppc
> # Ensure glibc{,-devel} is installed for both multilib arches
> BuildRequires: glibc-devel(%{__isa_name}-32)
> BuildRequires: glibc-devel(%{__isa_name}-64)
> %endif

I'll file a bug against gcc for this and ask them to
change it such that it can stop relying on the paths
to those DSOs.

> > What problems do you see?
> 
> Rpm tracks file presence in ways that cant be done with virtual provides.
> For example:
> 
> [pmatilai@localhost ~]$ rpm -q glibc
> glibc-2.17-11.fc19.x86_64
> glibc-2.17-11.fc19.i686
> [pmatilai@localhost ~]$ rpm -qf /sbin/ldconfig 
> glibc-2.17-11.fc19.x86_64
> [pmatilai@localhost ~]$ 
> 
> glibc.i686 package contains /sbin/ldconfig too, but on x86_64 system that
> file doesn't actually get installed, its "shadowed" by the one from x86_64.
> As rpm remembers this, the installed glibc.i686 doesn't provide
> /sbin/ldconfig at all, with virtually provided /sbin/ldconfig such tricks
> stop working which can affect installation ordering, dependency resolution
> etc.
> 
> This probably wont make much of a difference with glibc as anything
> depending on /sbin/ldconfig will always have other dependencies to glibc
> too, but the point is that virtually provided files are not at all equal to
> implicitly provided actual files in a package.

Thank you for explaining that.

I think the next steps are:

* Close this issue as CLOSED/NOTABUG
* Have glibc use Provides: to provide all binaries normally provided.
* Ensure that during the upgrade the ABI mandated path still exists e.g. /lib, /lib64 (can never go away easily and will be part of the `Move to /usr' requirement that is never met).
* Push to rawhide and start filling bugs against packages that use absolute paths to glibc libraries and fix them.

Comments?

Cheers,
Carlos.
Comment 8 Panu Matilainen 2013-08-20 03:24:18 EDT
I'd recommend waiting for the outcome of https://fedorahosted.org/fpc/ticket/314 before proceeding with further changes, especially wrt executables like /sbin/ldconfig.

Other than that, I dont see anything special required from rpm side so NOTABUG seems appropriate.

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