While playing with custom repos I noticed that libgcj-devel requires a file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 environmentment this requires looking at the file lists to see that libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package is at fault. I was hoping to get some guidance here on whether or not this is something I should bugzilla.
On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
While playing with custom repos I noticed that libgcj-devel requires a file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 environmentment this requires looking at the file lists to see that libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package is at fault. I was hoping to get some guidance here on whether or not this is something I should bugzilla.
I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs the i386 version of that package - not the x86_64.
-sv
On Mon, Sep 22, 2008 at 12:40:10 -0400, seth vidal skvidal@fedoraproject.org wrote:
On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
While playing with custom repos I noticed that libgcj-devel requires a file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 environmentment this requires looking at the file lists to see that libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package is at fault. I was hoping to get some guidance here on whether or not this is something I should bugzilla.
I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs the i386 version of that package - not the x86_64.
It requires a specific lib file that is different between the i386 and x86_64 versions of zlib-devel. However the different files are not "provide"d by either zlib so you can't find the dependceny without using the file lists.
There are over 700 -devel rpms in Fedora where the i386 version of the package doesn't "provide" anything not "provide"d by the x86_64 version. presumably most of these put their libs in different places and they get pulled in because yum (or whatever) ends up looking through the file lists.
(There are also a lot (nearly 3000) of the i386 rpms in fedora that "provide" something not provided by any x86_64 packages, but are not included in the normal x86_64 rawhide repo. This seems odd, but not strictly an error. My supposition is that a lot of these packages have a gratiutious (x86-32) provides, but I really haven't look into it.)
In a couple of cases I looked at things are even more broken. For example nspr-devel is needed by nss-devel and there do appear to be differences between the i386 and x86_64 libraries, yet the requires for nss-devel to not require anything that is not provided by the x86_64 version of nspr-devel. I am not 100% sure this is broken, but it looks wrong to me.
[root@cerberus Packages]# rpm -q --provides -p nspr-devel-4.7.1-2.fc10.i386.rpm nspr-devel = 4.7.1-2.fc10 [root@cerberus Packages]# rpm -q --requires -p nss-devel-3.12.1.1-2.fc10.i386.rpm /bin/sh libfreebl3.so libnss3.so libnssckbi.so libnssdbm3.so libnsspem.so libnssutil3.so libsmime3.so libsoftokn3.so libssl3.so nspr-devel >= 4.7 nss = 3.12.1.1-2.fc10 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 [root@cerberus Packages]# rpm -qlp ../../x86_64/Packages/nspr-devel-4.7.1-2.fc10.x86_64.rpm /usr/bin/nspr-config /usr/include/nspr4 /usr/include/nspr4/nspr.h /usr/include/nspr4/obsolete /usr/include/nspr4/obsolete/pralarm.h /usr/include/nspr4/obsolete/probslet.h /usr/include/nspr4/obsolete/protypes.h /usr/include/nspr4/obsolete/prsem.h /usr/include/nspr4/plarena.h /usr/include/nspr4/plarenas.h /usr/include/nspr4/plbase64.h /usr/include/nspr4/plerror.h /usr/include/nspr4/plgetopt.h /usr/include/nspr4/plhash.h /usr/include/nspr4/plresolv.h /usr/include/nspr4/plstr.h /usr/include/nspr4/pratom.h /usr/include/nspr4/prbit.h /usr/include/nspr4/prclist.h /usr/include/nspr4/prcmon.h /usr/include/nspr4/prcountr.h /usr/include/nspr4/prcpucfg.h /usr/include/nspr4/prcvar.h /usr/include/nspr4/prdtoa.h /usr/include/nspr4/prenv.h /usr/include/nspr4/prerr.h /usr/include/nspr4/prerror.h /usr/include/nspr4/prinet.h /usr/include/nspr4/prinit.h /usr/include/nspr4/prinrval.h /usr/include/nspr4/prio.h /usr/include/nspr4/pripcsem.h /usr/include/nspr4/private /usr/include/nspr4/private/pprio.h /usr/include/nspr4/private/pprthred.h /usr/include/nspr4/private/prpriv.h /usr/include/nspr4/prlink.h /usr/include/nspr4/prlock.h /usr/include/nspr4/prlog.h /usr/include/nspr4/prlong.h /usr/include/nspr4/prmem.h /usr/include/nspr4/prmon.h /usr/include/nspr4/prmwait.h /usr/include/nspr4/prnetdb.h /usr/include/nspr4/prolock.h /usr/include/nspr4/prpdce.h /usr/include/nspr4/prprf.h /usr/include/nspr4/prproces.h /usr/include/nspr4/prrng.h /usr/include/nspr4/prrwlock.h /usr/include/nspr4/prshm.h /usr/include/nspr4/prshma.h /usr/include/nspr4/prsystem.h /usr/include/nspr4/prthread.h /usr/include/nspr4/prtime.h /usr/include/nspr4/prtpool.h /usr/include/nspr4/prtrace.h /usr/include/nspr4/prtypes.h /usr/include/nspr4/prvrsion.h /usr/include/nspr4/prwin16.h /usr/lib64/libnspr4.so /usr/lib64/libplc4.so /usr/lib64/libplds4.so /usr/lib64/pkgconfig/nspr.pc
On Mon, 2008-09-22 at 13:26 -0500, Bruno Wolff III wrote:
On Mon, Sep 22, 2008 at 12:40:10 -0400, seth vidal skvidal@fedoraproject.org wrote:
On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
While playing with custom repos I noticed that libgcj-devel requires a file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 environmentment this requires looking at the file lists to see that libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package is at fault. I was hoping to get some guidance here on whether or not this is something I should bugzilla.
I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs the i386 version of that package - not the x86_64.
It requires a specific lib file that is different between the i386 and x86_64 versions of zlib-devel. However the different files are not "provide"d by either zlib so you can't find the dependceny without using the file lists.
There are over 700 -devel rpms in Fedora where the i386 version of the package doesn't "provide" anything not "provide"d by the x86_64 version. presumably most of these put their libs in different places and they get pulled in because yum (or whatever) ends up looking through the file lists.
Yes - that's a file dep - that's how they work. I'm not a big fan of them, either.
If you'd like to lead a crusade to get rid of them I'll happily follow but seeing as I've tried it twice I'm not going to lead another one :)
-sv
On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote:
If you'd like to lead a crusade to get rid of them I'll happily follow but seeing as I've tried it twice I'm not going to lead another one :)
In this case, wouldn't it be something that we could use the new rpm isa-provides for?
Requires: zlib-devel(x86-32)
Of course, that doesn't seem to be working right now in rawhide... but I think all we'd need to do is rebuild zlib.
~spot
On Mon, 2008-09-22 at 15:27 -0400, Tom "spot" Callaway wrote:
On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote:
If you'd like to lead a crusade to get rid of them I'll happily follow but seeing as I've tried it twice I'm not going to lead another one :)
In this case, wouldn't it be something that we could use the new rpm isa-provides for?
Requires: zlib-devel(x86-32)
Of course, that doesn't seem to be working right now in rawhide... but I think all we'd need to do is rebuild zlib.
indeed - except we'd have to make that work per-arch b/c zlib-devel (x86-32) isn't going to work so well on ppc64
-sv
On Mon, 22 Sep 2008, seth vidal wrote:
On Mon, 2008-09-22 at 15:27 -0400, Tom "spot" Callaway wrote:
On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote:
If you'd like to lead a crusade to get rid of them I'll happily follow but seeing as I've tried it twice I'm not going to lead another one :)
In this case, wouldn't it be something that we could use the new rpm isa-provides for?
Requires: zlib-devel(x86-32)
Of course, that doesn't seem to be working right now in rawhide... but I think all we'd need to do is rebuild zlib.
indeed - except we'd have to make that work per-arch b/c zlib-devel (x86-32) isn't going to work so well on ppc64
Well obviously you don't want to use literal, hardcoded "Requires: zlib-devel(x86-32)" in the spec, but this instead:
Requires: zlib-devel%{?_isa}
That gets expanded at build time to the ISA name of the package being built. And it's backwards compatible in the sense that if built with older rpm, you get just "Requires: zlib-devel" like before.
And yes this is one of the major cases for which the whole ISA-thingie was invented. What's missing is the mass-rebuild to make the ISA-provides globally available, and FPC guidelines on using them.
- Panu -
Panu Matilainen wrote:
Well obviously you don't want to use literal, hardcoded "Requires: zlib-devel(x86-32)" in the spec, but this instead:
Requires: zlib-devel%{?_isa}
...
And yes this is one of the major cases for which the whole ISA-thingie was invented. What's missing is the mass-rebuild to make the ISA-provides globally available, and FPC guidelines on using them.
Thanks Panu, this will certainly be a very welcome new rpm feature.
-- Rex
On Mon, Sep 22, 2008 at 14:29:05 -0400, seth vidal skvidal@fedoraproject.org wrote:
Yes - that's a file dep - that's how they work. I'm not a big fan of them, either.
If you'd like to lead a crusade to get rid of them I'll happily follow but seeing as I've tried it twice I'm not going to lead another one :)
Right now I am cla only and not in a good position to lead packaging initiatives. (I want to eventually be a packager, but the code I have a particular interest in packaging is written in java which I not that familiar with and needs to have have copyrighted images scrubbed and will still need to be looked at further because it is based on a boardgame.)
I don't think finding references to files and changing the providing packages to explicitly provide them would be all that hard. While this would speed up yum in some cases I am not sure this is really the right approach. Someone really needs to think about how provides/requires should be used and how multilib will interact with this. I suspect this wouldn't be a high priority initiative. The benefits would be faster yum and rpm (since filelist checks for requirements could be skipped) and perhaps a better way to figure out which i386 packages should be included in the x86_64 repo.
On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote:
Right now I am cla only and not in a good position to lead packaging initiatives. (I want to eventually be a packager, but the code I have a particular interest in packaging is written in java which I not that familiar with and needs to have have copyrighted images scrubbed and will still need to be looked at further because it is based on a boardgame.)
I don't think finding references to files and changing the providing packages to explicitly provide them would be all that hard.
Changing the pkgs AFTER the fact?
-sv
On Mon, Sep 22, 2008 at 15:47:51 -0400, seth vidal skvidal@fedoraproject.org wrote:
On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote:
Right now I am cla only and not in a good position to lead packaging initiatives. (I want to eventually be a packager, but the code I have a particular interest in packaging is written in java which I not that familiar with and needs to have have copyrighted images scrubbed and will still need to be looked at further because it is based on a boardgame.)
I don't think finding references to files and changing the providing packages to explicitly provide them would be all that hard.
Changing the pkgs AFTER the fact?
This would require new releases. Only the providing packages would need to be changed to explicitly provide the capability corresponding to the file. It's a LOT of grunt work, but not hard. This wouldn't break anything. It doesn't even all need to be done at the same time. It would increase the list of capabilities a couple of % (based on roughly 50000 capabilities in a repo and on the order of 1000 packages that likely implicitly provide files as capabilities). This wouldn't stop people from making new ones. To do that you'd need to change yum/rpm to not work if they did. That would be a big change that you'd want to do for a Fedora release.
However, I suspect that putting in all of those provides is something that the project would want to undo later. (After thinking about about how it would really be best to do things something other than file names might end up being used.) So I doubt it is worth the work to do this. (At least not before long term goals are set.)
If the (x86-32) stuff is relatively automatic it might be worth getting a list of packages which would take advantage of this and get them rebuilt. I don't know much about that feature, just waht Spot referred to and that I saw a lot of capabilities with the string '(x86-32)' in them. Cleaning up packages to make reference to the x86-32 capabilities might be harder.
On Mon, 22 Sep 2008, Bruno Wolff III wrote:
On Mon, Sep 22, 2008 at 15:47:51 -0400, seth vidal skvidal@fedoraproject.org wrote:
On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote:
Right now I am cla only and not in a good position to lead packaging initiatives. (I want to eventually be a packager, but the code I have a particular interest in packaging is written in java which I not that familiar with and needs to have have copyrighted images scrubbed and will still need to be looked at further because it is based on a boardgame.)
I don't think finding references to files and changing the providing packages to explicitly provide them would be all that hard.
Changing the pkgs AFTER the fact?
This would require new releases. Only the providing packages would need to be changed to explicitly provide the capability corresponding to the file. It's a LOT of grunt work, but not hard. This wouldn't break anything. It doesn't even all need to be done at the same time. It would increase the list of capabilities a couple of % (based on roughly 50000 capabilities in a repo and on the order of 1000 packages that likely implicitly provide files as capabilities). This wouldn't stop people from making new ones. To do that you'd need to change yum/rpm to not work if they did. That would be a big change that you'd want to do for a Fedora release.
However, I suspect that putting in all of those provides is something that the project would want to undo later. (After thinking about about how it would really be best to do things something other than file names might end up being used.) So I doubt it is worth the work to do this. (At least not before long term goals are set.)
If the (x86-32) stuff is relatively automatic it might be worth getting a list of packages which would take advantage of this and get them rebuilt. I don't know much about that feature, just waht Spot referred to and that I saw a lot of capabilities with the string '(x86-32)' in them. Cleaning up packages to make reference to the x86-32 capabilities might be harder.
The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.
The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such
Due to a) and b), almost everything in the distro could benefit from using them. For one, if all the relevant BuildRequires: are made to use ISA-provides instead of just the package name, we wouldn't need the monster exclude-lines in mock configs for multilib-capable systems to guarantee sane results.
- Panu -
On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote:
The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.
The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such
Which kinds of problems does this solve?
So far I don't see any. Conversely, AFAIU all this does, is to add more incompatibilities, more rpmdb entries, all for information which already is hidden somewhere else.
Ralf
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote:
The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.
The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such
Which kinds of problems does this solve?
If it wasn't obvious from the list above... a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to satisfy foo-devel.x86_64 which is obviously not correct. b) Similarly to a), BuildRequires: foo-devel. Currently, if you have foo-devel.i386 installed and try to build for x86_64, it's considered satisfied which is obviously not correct. c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin needs to be of compatible arch to work, quite obviously. The only way to express this correctly right now is to use file dependencies on %{_libdir}/something.
So far I don't see any. Conversely, AFAIU all this does, is to add more incompatibilities, more rpmdb entries, all for information which already is hidden somewhere else.
So you'd rather change all -devel and build dependencies to %{_libdir}/libfoo.so file dependencies? And there's no incompatibility here, specs remain backwards compatible as long as you use the conditional %{?_isa} construct for this.
- Panu -
On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote:
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote:
The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.
The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such
Which kinds of problems does this solve?
If it wasn't obvious from the list above... a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to satisfy foo-devel.x86_64 which is obviously not correct.
bug in rpm's version comparison => Your addition doesn't solve it.
b) Similarly to a), BuildRequires: foo-devel. Currently, if you have foo-devel.i386 installed and try to build for x86_64, it's considered satisfied which is obviously not correct.
same as above.
c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin needs to be of compatible arch to work, quite obviously. The only way to express this correctly right now is to use file dependencies on %{_libdir}/something.
Correct. You don't solve anything that file-deps would not solve.
So far I don't see any. Conversely, AFAIU all this does, is to add more incompatibilities, more rpmdb entries, all for information which already is hidden somewhere else.
So you'd rather change all -devel and build dependencies to %{_libdir}/libfoo.so file dependencies?
Correct. I think, all what these rpm meta-tag do is to add pollution to the rpmdb, to solve a problem to which file-deps would be an already existing "natural solution", because they actually are file deps at run-time.
And there's no incompatibility here, specs remain backwards compatible as long as you use the conditional %{?_isa} construct for this.
More pollution to rpmdb, more sources of errors and conflicts.
Ralf
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote:
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote:
The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.
The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such
Which kinds of problems does this solve?
If it wasn't obvious from the list above... a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to satisfy foo-devel.x86_64 which is obviously not correct.
bug in rpm's version comparison => Your addition doesn't solve it.
No. There hasn't been a way to specify dependency on certain architecture, rpm has no way of knowing if "foo" in "Requires: foo" is supposed to be same arch or not.
Sure it would be possible to teach rpm to grok the name.arch syntax for (build)requires too, but it would require changing every depsolver to understand it too, and *that* would be incompatible change in spec syntax as well. Whereas the new provide introduces precisely zero incompatibilities.
b) Similarly to a), BuildRequires: foo-devel. Currently, if you have foo-devel.i386 installed and try to build for x86_64, it's considered satisfied which is obviously not correct.
same as above.
Same as above.
c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin needs to be of compatible arch to work, quite obviously. The only way to express this correctly right now is to use file dependencies on %{_libdir}/something.
Correct. You don't solve anything that file-deps would not solve.
So far I don't see any. Conversely, AFAIU all this does, is to add more incompatibilities, more rpmdb entries, all for information which already is hidden somewhere else.
So you'd rather change all -devel and build dependencies to %{_libdir}/libfoo.so file dependencies?
Correct. I think, all what these rpm meta-tag do is to add pollution to the rpmdb, to solve a problem to which file-deps would be an already existing "natural solution", because they actually are file deps at run-time.
Except there isn't always an "arch-specific" file you can depend on. Often there is, but not always. File-dependencies are more expensive to look up than regular provides.
If file dependencies on things like /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar are so wonderfully perfect solution to the problem at hand, I wonder why people aren't using them for everything then.
- Panu -
Le Mar 23 septembre 2008 11:54, Panu Matilainen a écrit :
Sure it would be possible to teach rpm to grok the name.arch syntax for (build)requires too, but it would require changing every depsolver to understand it too, and *that* would be incompatible change in spec syntax as well. Whereas the new provide introduces precisely zero incompatibilities.
But that would fix the problem once and for all wouldn't it? Are the other solutions so fool-proof they won't need to be revised anyway?
On Tue, 23 Sep 2008, Nicolas Mailhot wrote:
Le Mar 23 septembre 2008 11:54, Panu Matilainen a écrit :
Sure it would be possible to teach rpm to grok the name.arch syntax for (build)requires too, but it would require changing every depsolver to understand it too, and *that* would be incompatible change in spec syntax as well. Whereas the new provide introduces precisely zero incompatibilities.
But that would fix the problem once and for all wouldn't it? Are the other solutions so fool-proof they won't need to be revised anyway?
Plain name.arch syntax in dependencies has it's own problems, see the sub-thread starting here: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00056.html
That's not to say support for it couldn't be added but using it would cause a huge incompatibilities all over the place for little gain.
- Panu -
On Tue, 2008-09-23 at 12:54 +0300, Panu Matilainen wrote:
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote:
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote:
The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.
The main use-cases for this feature are: a) -devel package dependencies on other -devel packages b) BuildRequires c) manual dependencies for plugins and such
Which kinds of problems does this solve?
If it wasn't obvious from the list above... a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to satisfy foo-devel.x86_64 which is obviously not correct.
bug in rpm's version comparison => Your addition doesn't solve it.
No. There hasn't been a way to specify dependency on certain architecture,
Exactly: This is the BUG in *RPM*.
rpm has no way of knowing if "foo" in "Requires: foo" is supposed to be same arch or not.
Right, but it could (and should have done so for ages) The information is present.
Sure it would be possible to teach rpm to grok the name.arch syntax for (build)requires too, but it would require changing every depsolver to understand it too,
Correct, that's another bug. The depsolver should be part of RPM.
c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin needs to be of compatible arch to work, quite obviously. The only way to express this correctly right now is to use file dependencies on %{_libdir}/something.
Correct. You don't solve anything that file-deps would not solve.
So far I don't see any. Conversely, AFAIU all this does, is to add more incompatibilities, more rpmdb entries, all for information which already is hidden somewhere else.
So you'd rather change all -devel and build dependencies to %{_libdir}/libfoo.so file dependencies?
Correct. I think, all what these rpm meta-tag do is to add pollution to the rpmdb, to solve a problem to which file-deps would be an already existing "natural solution", because they actually are file deps at run-time.
Except there isn't always an "arch-specific" file you can depend on.
And where is the problem?
A "client" package which depends on some "provider" almost always depends on the provider to provide a file, no matter what this file actually is.
I.e. you hardly ever need the "architecture", you almost always need the file and nothing else.
Often there is, but not always. File-dependencies are more expensive to look up than regular provides.
Wrong. Inside of rpm everything is database lookups. Whether these are file-deps or artificial provides doesn't matter. Whether rpm/yum etc. handle them efficiently, is a different matter.
If file dependencies on things like /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar are so wonderfully perfect solution to the problem at hand, I wonder why people aren't using them for everything then.
Lack of insight, people being subject to FUD/propaganda for years? People being confused by the very few corner cases (SONAMES)?
Ralf
On Tue, Sep 23, 2008 at 10:19:54 +0200, Ralf Corsepius rc040203@freenet.de wrote:
On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote:
On Tue, 23 Sep 2008, Ralf Corsepius wrote:
If it wasn't obvious from the list above... a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to satisfy foo-devel.x86_64 which is obviously not correct.
bug in rpm's version comparison => Your addition doesn't solve it.
How are you going to automatically tell in which cases you need to match arch and which ones you don't? It looks like you are going to have to touch a bunch of requires or provides in any case.
So you'd rather change all -devel and build dependencies to %{_libdir}/libfoo.so file dependencies?
Correct. I think, all what these rpm meta-tag do is to add pollution to the rpmdb, to solve a problem to which file-deps would be an already existing "natural solution", because they actually are file deps at run-time.
For libraries, shouldn't the dependency just be on the library name and arch, not the actual filename path? The library file could go into one of several directories and still be available.
More pollution to rpmdb, more sources of errors and conflicts.
Don't you consider treating all of the filenames installed by a package as what amounts to provided capabilities, as pollution?
I would think you wouldn't want packages requiring just any old file out of a package in order to express a dependency on it.
seth vidal wrote:
On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
While playing with custom repos I noticed that libgcj-devel requires a file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 environmentment this requires looking at the file lists to see that libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package is at fault. I was hoping to get some guidance here on whether or not this is something I should bugzilla.
I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs the i386 version of that package - not the x86_64.
do you know what is the technical reason for this dependency ? Exotic build system ?
Denis Leroy wrote:
seth vidal wrote:
On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
While playing with custom repos I noticed that libgcj-devel requires a file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386 environmentment this requires looking at the file lists to see that libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package is at fault. I was hoping to get some guidance here on whether or not this is something I should bugzilla.
I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs the i386 version of that package - not the x86_64.
do you know what is the technical reason for this dependency ? Exotic build system ?
With a simple bump and rebuild of zlib (using the new rpm), zlib-devel would pick up provides of zlib-devel%{?_isa} (on i386 this would be zlib-devel(x86-32) and on x86_64 it would be zlib-devel(x86-64)). Dependencies of zlib-devel%{?_isa} could then be added in other packages where needed.
Ideally there would be a mass rebuild prior to F10 of all packages where this is likely to be useful (e.g. everything providing a -devel package) that have not been rebuilt using the new rpm. This would ensure that spec files using %{?_isa} dependencies would be compatible with all supported Fedora releases after F10 goes gold. By this I mean that in F9 the expansion of the %{?_isa} macro would be empty and hence transparent, and for F10 onwards, any package that might be expected to provide %{?_isa} dependencies will do so. Without a rebuild prior to F10, it's possible for instance that a rebuild of zlib early in F11 development could lead to F11 packages having zlib-devel%{?_isa} dependencies added, but packages built from the same spec files on F10 would have broken deps because the zlib-devel%{?_isa} dependency would be unsatisfied there.
Paul.
packaging@lists.fedoraproject.org
-
Bruno Wolff III -
Denis Leroy -
Nicolas Mailhot -
Panu Matilainen -
Paul Howarth -
Ralf Corsepius -
Rex Dieter -
Seth Vidal -
Tom Callaway