11:33 a.m.
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.
11:40 a.m.
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
1:26 p.m.
On Mon, Sep 22, 2008 at 12:40:10 -0400,
seth vidal <skvidal(a)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
1:29 p.m.
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(a)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
2:27 p.m.
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
2:30 p.m.
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
1 a.m.
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 -
8:51 a.m.
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
2:45 p.m.
On Mon, Sep 22, 2008 at 14:29:05 -0400,
seth vidal <skvidal(a)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.
2:47 p.m.
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
3:12 p.m.
On Mon, Sep 22, 2008 at 15:47:51 -0400,
seth vidal <skvidal(a)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.
1:18 a.m.
On Mon, 22 Sep 2008, Bruno Wolff III wrote:
On Mon, Sep 22, 2008 at 15:47:51 -0400,
seth vidal <skvidal(a)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 -
1:26 a.m.
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
1:49 a.m.
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 -
3:19 a.m.
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
4:54 a.m.
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 -
5:52 a.m.
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?
--
Nicolas Mailhot
7:51 a.m.
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 -
6:25 a.m.
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
8:44 a.m.
On Tue, Sep 23, 2008 at 10:19:54 +0200,
Ralf Corsepius <rc040203(a)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.
8:06 a.m.
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 ?
10:36 a.m.
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.
5685
days inactive
5694
days old
packaging@lists.fedoraproject.org
21 comments
9 participants
participants (9)
-
Bruno Wolff III -
Denis Leroy -
Nicolas Mailhot -
Panu Matilainen -
Paul Howarth -
Ralf Corsepius -
Rex Dieter -
Seth Vidal -
Tom Callaway