Has anyone else seen a problem with nemiver i386 package not being available? There is an update in x86_64, and the matching version is actually present on the mirror for i386, but its not being shown as available through yum. This was causing updates to fail even with skip-broken, so I had to --exclude it.
Both packages are there: http://limestone.uoregon.edu/ftp/fedora/development/x86_64/os/Packages/nemiv... http://limestone.uoregon.edu/ftp/fedora/development/i386/os/Packages/nemiver...
But only x86_64 tries to update.
10:05:03 |lordmorgul.durthangnix:0| |17 files:11M@~| |0 jobs| - yum list nemiver.x86_64 nemiver.i386 Loaded plugins: basearchonly, fastestmirror, fedorakmod, priorities, security, : versionlock Loading mirror speeds from cached hostfile * livna-development: mirrors.tummy.com * livna-development-debuginfo: mirrors.tummy.com * rawhide: limestone.uoregon.edu * upstart-debuginfo: notting.fedorapeople.org * upstart: notting.fedorapeople.org Reading version lock configuration Installed Packages nemiver.x86_64 0.4.0-3.fc9 installed nemiver.i386 0.4.0-3.fc9 installed Available Packages nemiver.x86_64 0.5.1-1.fc9 rawhide
10:05:22 |lordmorgul.durthangnix:0| |17 files:11M@~| |0 jobs| - yum list updates Loaded plugins: basearchonly, fastestmirror, fedorakmod, priorities, security, : versionlock Loading mirror speeds from cached hostfile * livna-development: mirrors.tummy.com * livna-development-debuginfo: mirrors.tummy.com * rawhide: limestone.uoregon.edu * upstart-debuginfo: notting.fedorapeople.org * upstart: notting.fedorapeople.org Skipping security plugin, no data Reading version lock configuration Updated Packages evince.x86_64 2.22.0-3.fc9 rawhide inkscape.x86_64 0.46-0.3.pre3.fc9 rawhide kpathsea.x86_64 2007-28.fc9 rawhide nemiver.x86_64 0.5.1-1.fc9 rawhide poppler.x86_64 0.7.3-1.fc9 rawhide poppler-glib.x86_64 0.7.3-1.fc9 rawhide poppler-qt.x86_64 0.7.3-1.fc9 rawhide poppler-qt4.x86_64 0.7.3-1.fc9 rawhide texlive.x86_64 2007-28.fc9 rawhide texlive-dvips.x86_64 2007-28.fc9 rawhide texlive-latex.x86_64 2007-28.fc9 rawhide texlive-utils.x86_64 2007-28.fc9 rawhide
10:07:39 |lordmorgul.durthangnix:0| |17 files:11M@~| |0 jobs| - rpm -q nemiver.x86_64 nemiver.i386 nemiver-0.4.0-3.fc9.x86_64 nemiver-0.4.0-3.fc9.i386
On Mon, 2008-03-24 at 21:28 -0700, Andrew Farris wrote:
Both packages are there: http://limestone.uoregon.edu/ftp/fedora/development/x86_64/os/Packages/nemiv... http://limestone.uoregon.edu/ftp/fedora/development/i386/os/Packages/nemiver...
Actually, the package _isn't_ there. They should both be in the x86_64 tree (the i386 package simply duplicated into it). However, only the nemiver-devel.i386 is present, the base nemiver.i386 package is not there.
I can confirm that this also seems to happen with the download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the repo, since the devel subpackage contains an explicit dependency on the main package of the same NVR. Hmm. :|
Peter Gordon wrote:
Actually, the package _isn't_ there. They should both be in the x86_64 tree (the i386 package simply duplicated into it). However, only the nemiver-devel.i386 is present, the base nemiver.i386 package is not there.
Oh yes, good point.
I can confirm that this also seems to happen with the download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the repo, since the devel subpackage contains an explicit dependency on the main package of the same NVR. Hmm. :|
Well hopefully the repo compose does not do this again. I'll probably file a bug if it isn't fixed tomorrow morning.
On Mon, 2008-03-24 at 22:37 -0700, Peter Gordon wrote:
Actually, the package _isn't_ there. They should both be in the x86_64 tree (the i386 package simply duplicated into it). However, only the nemiver-devel.i386 is present, the base nemiver.i386 package is not there.
I can confirm that this also seems to happen with the download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the repo, since the devel subpackage contains an explicit dependency on the main package of the same NVR. Hmm. :|
Actually it looks like a packaging bug. nemiver-devel-0.5.1-1.fc9.i386 has a require of nemiver-0.5.1-1.fc9, which nemiver-0.5.1-1.fc9.x86_64 satisfies. Usually a -devel package will have a .so symlink to an actual library file that is in an arch specific package, which is how the arch specific multilib package gets pulled into the repo.
What is it about the nemiver-devel.i386 that absolutely requires nemiver.i386 instead of nemiver.x86_64?
On Tue, 25 Mar 2008 07:40:35 -0400, Jesse Keating wrote:
On Mon, 2008-03-24 at 22:37 -0700, Peter Gordon wrote:
Actually, the package _isn't_ there. They should both be in the x86_64 tree (the i386 package simply duplicated into it). However, only the nemiver-devel.i386 is present, the base nemiver.i386 package is not there.
I can confirm that this also seems to happen with the download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the repo, since the devel subpackage contains an explicit dependency on the main package of the same NVR. Hmm. :|
Actually it looks like a packaging bug. nemiver-devel-0.5.1-1.fc9.i386 has a require of nemiver-0.5.1-1.fc9, which nemiver-0.5.1-1.fc9.x86_64 satisfies. Usually a -devel package will have a .so symlink to an actual library file that is in an arch specific package, which is how the arch specific multilib package gets pulled into the repo.
The packaging suffers also from another bug. libnemicommon.pc refers to libnemicommon.so in default search path, but in the main package the library is in /usr/lib/nemiver/ Even if the search path were adjusted, linking to it with -lnemicommon would fail later at run-time (and indeed, the nemiver executable sets: 0x0000000f (RPATH) Library rpath: [/usr/lib/nemiver]
What is it about the nemiver-devel.i386 that absolutely requires nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
What is it about the nemiver-devel.i386 that absolutely requires nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
That means it should require those 32-bit libs. Ideally this requires would happen automatically, through the use of a .so symlink to a versioned arch specific shared object. However I gather that this isn't necessarily C so there is no symlink. I hate that we would have to add yet another file requires here.
On Tue, 25 Mar 2008 09:32:27 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
What is it about the nemiver-devel.i386 that absolutely requires nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
That means it should require those 32-bit libs. Ideally this requires would happen automatically, through the use of a .so symlink to a versioned arch specific shared object. However I gather that this isn't necessarily C so there is no symlink. I hate that we would have to add yet another file requires here.
It is C/C++, and there is no .so symlink because the library uses a version-less SONAME and therefore uses a .so file name already.
On Tue, 2008-03-25 at 17:21 +0100, Michael Schwendt wrote:
On Tue, 25 Mar 2008 09:32:27 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
What is it about the nemiver-devel.i386 that absolutely requires nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
That means it should require those 32-bit libs. Ideally this requires would happen automatically, through the use of a .so symlink to a versioned arch specific shared object. However I gather that this isn't necessarily C so there is no symlink. I hate that we would have to add yet another file requires here.
It is C/C++, and there is no .so symlink because the library uses a version-less SONAME and therefore uses a .so file name already.
Got any clever thoughts on how to resolve this, without adding manual file deps?
On Tue, 25 Mar 2008 13:05:13 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 17:21 +0100, Michael Schwendt wrote:
On Tue, 25 Mar 2008 09:32:27 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
What is it about the nemiver-devel.i386 that absolutely requires nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
That means it should require those 32-bit libs. Ideally this requires would happen automatically, through the use of a .so symlink to a versioned arch specific shared object. However I gather that this isn't necessarily C so there is no symlink. I hate that we would have to add yet another file requires here.
It is C/C++, and there is no .so symlink because the library uses a version-less SONAME and therefore uses a .so file name already.
Got any clever thoughts on how to resolve this, without adding manual file deps?
Clever? Add a version to the soname after talking to upstream about it. If they think the library interface is not stable enough, they can still use .so.0 instead of just .so Alternatively, ship a dummy executable in the -devel package, which causes rpmbuild to create an automatic soname dep. ;)
On Tue, 2008-03-25 at 20:30 +0100, Michael Schwendt wrote:
Clever? Add a version to the soname after talking to upstream about it. If they think the library interface is not stable enough, they can still use .so.0 instead of just .so Alternatively, ship a dummy executable in the -devel package, which causes rpmbuild to create an automatic soname dep. ;)
Heh, ok, both of those went through my mind too, glad we're on the same page.
Peter Gordon, can you take this issue to upstream? We really would rather not see unversioned shared objects.
On Tue, 2008-03-25 at 07:40 -0400, Jesse Keating wrote:
Actually it looks like a packaging bug. nemiver-devel-0.5.1-1.fc9.i386 has a require of nemiver-0.5.1-1.fc9, which nemiver-0.5.1-1.fc9.x86_64 satisfies. Usually a -devel package will have a .so symlink to an actual library file that is in an arch specific package, which is how the arch specific multilib package gets pulled into the repo.
Thanks, Jesse & Michael.
I looked into it a bit further and this does indeed seem to be a bug on the package itself. In 0.4.0, the -devel properly held a symlink to the original library, but because that was moved in the 0.5.x builds, that symlink was also removed (and thus the -devel package contains only data files: incude headers and the pkgconfig-foo).
What would be the best solution to resolve this? Should I add a symlink in the -devel subpackage manually? (This would resolve to within the % libdir/nemiver directory, too, which I think was one other bug that needed a squashing.)
On Tue, 2008-03-25 at 17:06 -0700, Peter Gordon wrote:
[...] data files: incude headers and the pkgconfig-foo).
Should read: "include headers ..."
Sorry for the typo!
On Tue, 25 Mar 2008 17:06:25 -0700, Peter Gordon wrote:
I looked into it a bit further and this does indeed seem to be a bug on the package itself. In 0.4.0, the -devel properly held a symlink to the original library, but because that was moved in the 0.5.x builds, that symlink was also removed (and thus the -devel package contains only data files: incude headers and the pkgconfig-foo).
What would be the best solution to resolve this? Should I add a symlink in the -devel subpackage manually? (This would resolve to within the % libdir/nemiver directory, too, which I think was one other bug that needed a squashing.)
Well, it would still require an rpath before linked programs would run (and rpaths are fragile, because the library may move to a different location). Because with a link like
%_libdir/libnemivercommon.so -> %_libdir/nemiver/libnemivercommon.so
you can -lnemivercommon at build-time, but at run-time the library is not found as it is located outside default search path. Strictly speaking, the package should not "Provides: libnemivercommon.so" either as long as the lib is provided in a private path (but rpmbuild doesn't know that, and hence you end up with automatic soname dependencies here, too).
I think I finally figured this out.
I was able to patch the build scripts a bit to build the nemivercommon shared library as a versioned DSO, and tweaked those same scripts to install to $LIBDIR instead of $LIBDIR/nemiver, so now we have in the main package:
/usr/lib64/libnemivercommon.so.0 -> libnemivercommon.so.0.0.0 /usr/lib64/libnemivercommon.so.0.0.0
And in the devel subpackage, the arch-specific, unversioned symlink is properly created:
/usr/lib64/libnemivercommon.so -> libnemivercommon.so.0.0.0
The nemiver binary properly is linked to the versioned DSO (libnemivercommon.so.0) so that works well, also.
I've just committed the update to CVS, and will let Koji churn through the builds while I get some much-needed sleep. =)
Assuming no problems, I'll sync the version update to F-8 and F-7 soon, too.
Thanks.
-
Andrew Farris -
Jesse Keating -
Michael Schwendt -
Peter Gordon