5:03 a.m.
Hello all:
I am hoping it is OK to discuss this here. I came across this problem
when I was building a custom spin where the kickstart file installs
'openmpi' before 'emacs'.
When I start emacs, here is what I get:
$emacs
emacs: error while loading shared libraries: libotf.so.0: cannot open
shared object file: No such file or directory
So, this library is missing. However, this should have been installed
as its a dependency, right?
It can be seen that there are two providers listed for libotf.so.0.
Since 'openmpi' was already installed, so it didn't bother installing
'libotf'. I could simulate the scenario on a Fedora 15 installation:
Step1: Dependency listing
---------------------------------
$yum deplist emacs
dependency: libotf.so.0
provider: openmpi.i686 1.5-3.fc15
provider: libotf.i686 0.9.12-2.fc15
To verify this scenario, the next step attempts to install emacs on a
machine without emacs, libotf and openmpi:
Step 2: Installing emacs
------------------------------
[gene@soma ~]$ sudo yum install emacs
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package emacs.i686 1:23.2-19.fc15 will be installed
--> Processing Dependency: libotf.so.0 for package: 1:emacs-23.2-19.fc15.i686
--> Running transaction check
---> Package libotf.i686 0:0.9.12-2.fc15 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================================
Package Arch Version
Repository Size
===========================================================================================
Installing:
emacs i686 1:23.2-19.fc15
updates 2.0 M
Installing for dependencies:
libotf i686 0.9.12-2.fc15
fedora 82 k
Transaction Summary
===========================================================================================
Install 2 Package(s)
Total download size: 2.1 M
all good here.
(I don't proceed with the install)
Step 3: Installing openmpi
------------------------------
Next, I just install openmpi, which is listed as a provider for libotf.so.0:
[gene@soma ~]$ sudo yum install openmpi
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openmpi.i686 0:1.5-3.fc15 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================================
Package Arch Version
Repository Size
===========================================================================================
Installing:
openmpi i686 1.5-3.fc15
fedora 1.7 M
Transaction Summary
===========================================================================================
Install 1 Package(s)
Total download size: 1.7 M
Installed size: 6.7 M
Install done.
Step 4: Installing Emacs after installing openmpi
---------------------------------------------------------------
[gene@soma ~]$ sudo yum install emacs
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package emacs.i686 1:23.2-19.fc15 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================================
Package Arch Version
Repository Size
===========================================================================================
Installing:
emacs i686 1:23.2-19.fc15
updates 2.0 M
Transaction Summary
===========================================================================================
Install 1 Package(s)
Total download size: 2.0 M
Installed size: 6.5 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 2.0 M
emacs-23.2-19.fc15.i686.rpm |
2.0 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : 1:emacs-23.2-19.fc15.i686
1/1
Installed:
emacs.i686 1:23.2-19.fc15
It doesn;t list the dependeny anymore on libotf.so.0, since openmpi is
already installed.
And the result:
$emacs
emacs: error while loading shared libraries: libotf.so.0: cannot open
shared object file: No such file or directory
I also noted this discrepancy:
$sudo yum whatprovides libotf.so.0
Loaded plugins: langpacks, presto, refresh-packagekit
openmpi-1.5-3.fc15.i686 : Open Message Passing Interface
Repo : fedora
Matched from:
Other : libotf.so.0
libotf-0.9.12-2.fc15.i686 : A Library for handling OpenType Font
Repo : fedora
Matched from:
Other : libotf.so.0
openmpi-1.5-3.fc15.i686 : Open Message Passing Interface
Repo : installed
Matched from:
Other : Provides-match: libotf.so.0
$sudo yum whatprovides libotf
Loaded plugins: langpacks, presto, refresh-packagekit
libotf-0.9.12-2.fc15.i686 : A Library for handling OpenType Font
Repo : fedora
Matched from:
Found some older bugs [1], [2], possibly related.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=527657
[2] https://bugzilla.redhat.com/show_bug.cgi?id=496131
Sorry for the long email, and I would be very happy to give any more
feedback or answer any further questions or file a bug.
-Amit
--
http://echorand.me
2:39 p.m.
On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
Hello all:
I am hoping it is OK to discuss this here. I came across this problem
when I was building a custom spin where the kickstart file installs
'openmpi' before 'emacs'.
When I start emacs, here is what I get:
$emacs
emacs: error while loading shared libraries: libotf.so.0: cannot open
shared object file: No such file or directory
So, this library is missing. However, this should have been installed
as its a dependency, right?
It can be seen that there are two providers listed for libotf.so.0.
Since 'openmpi' was already installed, so it didn't bother installing
'libotf'. I could simulate the scenario on a Fedora 15 installation:
The problem is that openmpi includes a libotf.so.0, but it's not in a
path that the system will usually look in for shared libraries, it's in
(libdir)/openmpi/lib/ . openmpi probably shouldn't have a private copy
of libotf in the first place (assuming that's what it is, and not just a
naming coincidence), but if it's going to have one, it should have a
line in the spec to prevent RPM auto-provides from giving the openmpi
package a Provides for libotf.so.0.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:46 p.m.
On Wed, 06 Jul 2011 12:39:14 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> So, this library is missing. However, this should have been
> installed as its a dependency, right?
>
> It can be seen that there are two providers listed for libotf.so.0.
> Since 'openmpi' was already installed, so it didn't bother
> installing 'libotf'. I could simulate the scenario on a Fedora 15
> installation:
The problem is that openmpi includes a libotf.so.0, but it's not in a
path that the system will usually look in for shared libraries, it's
in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
copy of libotf in the first place (assuming that's what it is, and
not just a naming coincidence), but if it's going to have one, it
should have a line in the spec to prevent RPM auto-provides from
giving the openmpi package a Provides for libotf.so.0.
It's certainly not the same libotf, since OpenMPI does not have
*anything* to do with truetype fonts.
Even though the library is installed in a non-system directory,
applications that link against libotf will get an automatically
generated Requires: against it anyways.
Maybe OpenMPI upstream should be contacted and asked to rename their
libotf.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
2:54 p.m.
On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote:
On Wed, 06 Jul 2011 12:39:14 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> > So, this library is missing. However, this should have been
> > installed as its a dependency, right?
> >
> > It can be seen that there are two providers listed for libotf.so.0.
> > Since 'openmpi' was already installed, so it didn't bother
> > installing 'libotf'. I could simulate the scenario on a Fedora 15
> > installation:
>
> The problem is that openmpi includes a libotf.so.0, but it's not in a
> path that the system will usually look in for shared libraries, it's
> in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
> copy of libotf in the first place (assuming that's what it is, and
> not just a naming coincidence), but if it's going to have one, it
> should have a line in the spec to prevent RPM auto-provides from
> giving the openmpi package a Provides for libotf.so.0.
It's certainly not the same libotf, since OpenMPI does not have
*anything* to do with truetype fonts.
Even though the library is installed in a non-system directory,
applications that link against libotf will get an automatically
generated Requires: against it anyways.
Well, packages get an auto-generated Requires: for libotf.so.0. Anything
that claims to provide libotf.so.0 will satisfy this. The most correct
solution is simply for openmpi to stop claiming to provide libotf.so.0
because, for practical purposes, it does not provide it: even if the
library in question were the same one, openmpi's copy is not in a
location that other packages will know how to use, so in practical
terms, it does not provide the library.
Maybe OpenMPI upstream should be contacted and asked to rename their
libotf.
This would also indeed make sense. Googling 'openmpi libotf' I see that
at least Gentoo and Debian have come across this before.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:02 p.m.
On Wed, 06 Jul 2011 12:54:48 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> It's certainly not the same libotf, since OpenMPI does not
have
> *anything* to do with truetype fonts.
>
> Even though the library is installed in a non-system directory,
> applications that link against libotf will get an automatically
> generated Requires: against it anyways.
Well, packages get an auto-generated Requires: for libotf.so.0.
Anything that claims to provide libotf.so.0 will satisfy this. The
most correct solution is simply for openmpi to stop claiming to
provide libotf.so.0 because, for practical purposes, it does not
provide it: even if the library in question were the same one,
openmpi's copy is not in a location that other packages will know how
to use, so in practical terms, it does not provide the library.
.. but on the other hand, the same logic applies in the opposite sense:
if something requires OpenMPI's libotf.so.0, also the truetype libotf
will satisfy the requirement. (Although openmpi apps typically link to
a half a dozen other openmpi libs as well).
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
3:09 p.m.
On Wed, 2011-07-06 at 23:02 +0300, Jussi Lehtola wrote:
On Wed, 06 Jul 2011 12:54:48 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> > It's certainly not the same libotf, since OpenMPI does not have
> > *anything* to do with truetype fonts.
> >
> > Even though the library is installed in a non-system directory,
> > applications that link against libotf will get an automatically
> > generated Requires: against it anyways.
>
> Well, packages get an auto-generated Requires: for libotf.so.0.
> Anything that claims to provide libotf.so.0 will satisfy this. The
> most correct solution is simply for openmpi to stop claiming to
> provide libotf.so.0 because, for practical purposes, it does not
> provide it: even if the library in question were the same one,
> openmpi's copy is not in a location that other packages will know how
> to use, so in practical terms, it does not provide the library.
.. but on the other hand, the same logic applies in the opposite sense:
if something requires OpenMPI's libotf.so.0, also the truetype libotf
will satisfy the requirement. (Although openmpi apps typically link to
a half a dozen other openmpi libs as well).
Nothing really could require OpenMPI's libotf as things stand, because
of what I wrote above: nothing can find it unless it uses a custom
linker path. If OpenMPI actually wanted the library to be something
other packages can use, it should really install it in a shared path
(and, as we've already discussed, rename it). If we're just talking
about different OpenMPI packages, they can handle the intra-dependencies
manually, I'd say.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:39 p.m.
On Wed, 06 Jul 2011 13:09:41 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> .. but on the other hand, the same logic applies in the
opposite
> sense: if something requires OpenMPI's libotf.so.0, also the
> truetype libotf will satisfy the requirement. (Although openmpi
> apps typically link to a half a dozen other openmpi libs as well).
Nothing really could require OpenMPI's libotf as things stand, because
of what I wrote above: nothing can find it unless it uses a custom
linker path. If OpenMPI actually wanted the library to be something
other packages can use, it should really install it in a shared path
(and, as we've already discussed, rename it). If we're just talking
about different OpenMPI packages, they can handle the
intra-dependencies manually, I'd say.
Not really, since when the MPI environment is loaded the relevant
library paths are added to LD_LIBRARY_PATH.
They're not installed in system locations, since e.g. all MPI libraries
ship with libmpi.so, and there are many variants: OpenMPI, MPICH2,
MVAPICH, and so on.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
3:42 p.m.
On Wed, 2011-07-06 at 23:39 +0300, Jussi Lehtola wrote:
On Wed, 06 Jul 2011 13:09:41 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> > .. but on the other hand, the same logic applies in the opposite
> > sense: if something requires OpenMPI's libotf.so.0, also the
> > truetype libotf will satisfy the requirement. (Although openmpi
> > apps typically link to a half a dozen other openmpi libs as well).
>
> Nothing really could require OpenMPI's libotf as things stand, because
> of what I wrote above: nothing can find it unless it uses a custom
> linker path. If OpenMPI actually wanted the library to be something
> other packages can use, it should really install it in a shared path
> (and, as we've already discussed, rename it). If we're just talking
> about different OpenMPI packages, they can handle the
> intra-dependencies manually, I'd say.
Not really, since when the MPI environment is loaded the relevant
library paths are added to LD_LIBRARY_PATH.
They're not installed in system locations, since e.g. all MPI libraries
ship with libmpi.so, and there are many variants: OpenMPI, MPICH2,
MVAPICH, and so on.
In that case it may be best just to get the library renamed, I guess.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:24 p.m.
Adam Williamson wrote on Wed, Jul 06, 2011 at 12:54:48PM -0700:
On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote:
> On Wed, 06 Jul 2011 12:39:14 -0700
> Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> > > So, this library is missing. However, this should have been
> > > installed as its a dependency, right?
> > >
> > > It can be seen that there are two providers listed for libotf.so.0.
> > > Since 'openmpi' was already installed, so it didn't bother
> > > installing 'libotf'. I could simulate the scenario on a Fedora 15
> > > installation:
> >
> > The problem is that openmpi includes a libotf.so.0, but it's not in a
> > path that the system will usually look in for shared libraries, it's
> > in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
> > copy of libotf in the first place (assuming that's what it is, and
> > not just a naming coincidence), but if it's going to have one, it
> > should have a line in the spec to prevent RPM auto-provides from
> > giving the openmpi package a Provides for libotf.so.0.
>
> It's certainly not the same libotf, since OpenMPI does not have
> *anything* to do with truetype fonts.
>
> Even though the library is installed in a non-system directory,
> applications that link against libotf will get an automatically
> generated Requires: against it anyways.
Well, packages get an auto-generated Requires: for libotf.so.0. Anything
that claims to provide libotf.so.0 will satisfy this. The most correct
solution is simply for openmpi to stop claiming to provide libotf.so.0
because, for practical purposes, it does not provide it: even if the
library in question were the same one, openmpi's copy is not in a
location that other packages will know how to use, so in practical
terms, it does not provide the library.
If I run into this kind of a situation (a false auto-generated
Provides), is it possible to disable just that one entry, or do I have
to disable AutoProv entirely and keep track of the libs myself?
Thanks,
-matyas
3:26 p.m.
On Wed, 2011-07-06 at 15:24 -0500, Mátyás Selmeci wrote:
> Well, packages get an auto-generated Requires: for libotf.so.0.
Anything
> that claims to provide libotf.so.0 will satisfy this. The most correct
> solution is simply for openmpi to stop claiming to provide libotf.so.0
> because, for practical purposes, it does not provide it: even if the
> library in question were the same one, openmpi's copy is not in a
> location that other packages will know how to use, so in practical
> terms, it does not provide the library.
If I run into this kind of a situation (a false auto-generated
Provides), is it possible to disable just that one entry, or do I have
to disable AutoProv entirely and keep track of the libs myself?
http://fedoraproject.org/wiki/AutoReqProv_%28draft%
29#Removing_items_from_the_provides_stream_.28post-scan_filtering.29
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:33 p.m.
On Wed, Jul 6, 2011 at 2:26 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
Or rather https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering,
and I can't use that in a couple of similar cases due to the
restrictions in the Usage section.
--
Jerry James
http://www.jamezone.org/
4:28 p.m.
On 07/06/2011 11:33 PM, Jerry James wrote:
On Wed, Jul 6, 2011 at 2:26 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
>
http://fedoraproject.org/wiki/AutoReqProv_%28draft%29#Removing_items_from...
Or rather https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering,
and I can't use that in a couple of similar cases due to the
restrictions in the Usage section.
For rpm >= 4.9, there's __provides_exclude and __provides_exclude_from
which I believe don't have those problems.
http://rpm.org/wiki/PackagerDocs/DependencyGenerator#TweakingDependencyGe...
5:46 p.m.
On Wed, Jul 6, 2011 at 3:28 PM, Ville Skyttä <ville.skytta(a)iki.fi> wrote:
For rpm >= 4.9, there's __provides_exclude and
__provides_exclude_from
which I believe don't have those problems.
http://rpm.org/wiki/PackagerDocs/DependencyGenerator#TweakingDependencyGe...
Oh, excellent! Thanks, Ville. That's F15+, I believe. Off to fix
some packages....
--
Jerry James
http://www.jamezone.org/
11:54 a.m.
On Wed, Jul 06, 2011 at 04:46:46PM -0600, Jerry James wrote:
On Wed, Jul 6, 2011 at 3:28 PM, Ville Skyttä
<ville.skytta(a)iki.fi> wrote:
> For rpm >= 4.9, there's __provides_exclude and __provides_exclude_from
> which I believe don't have those problems.
>
> http://rpm.org/wiki/PackagerDocs/DependencyGenerator#TweakingDependencyGe...
Oh, excellent! Thanks, Ville. That's F15+, I believe. Off to fix
some packages....
If you spend the time to figure out how to make these work, the FPC would
love to have the Guidelines that deal with Filtering updated. There's
a start of a draft linked from this ticket:
https://fedorahosted.org/fpc/ticket/76
but it's stuck because we need someone with enough experience with/knowledge
of the new implementation to finish up questions in the draft.
-Toshio
12:47 p.m.
On Thu, Jul 7, 2011 at 10:54 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
If you spend the time to figure out how to make these work, the FPC
would
love to have the Guidelines that deal with Filtering updated. There's
a start of a draft linked from this ticket:
https://fedorahosted.org/fpc/ticket/76
but it's stuck because we need someone with enough experience with/knowledge
of the new implementation to finish up questions in the draft.
-Toshio
Some of the questions were answered by a previous respondent, and I
just added a bit more information to the ticket from what little I've
learned so far.
--
Jerry James
http://www.jamezone.org/
4691
days inactive
4692
days old
14 comments
7 participants
participants (7)
-
Adam Williamson -
Amit Saha -
Jerry James -
Mátyás Selmeci -
Susi Lehtola -
Toshio Kuratomi -
Ville Skyttä