Hello, in perl, circular dependencies are heavily used.
First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem, rpm{,-libs} and python{,-libs} are doing the same. Let's put this aside.
Second, package "perl-devel" requires packages: perl-CPAN perl-ExtUtils-Embed perl-ExtUtils-MakeMaker perl-Test-Harness perl-Test-Simple all these packages require perl-devel, most of them by a direct requirement, only perl-CPAN by requiring perl-ExtUtils-Embed.
I believe this is correct: - the modules have to have separate rpm, to match the real situation: they use a separate versioning scheme, for example. - perl-devel has to require them; these modules are required by scripts packed in perl-devel
But this seems to bring problems, see the comments in https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7
Is this just a bug in yum, or is there a problem on my side?
Thanks, Stepan Kasal
On Tuesday 21 August 2007, Stepan Kasal wrote:
Hello, in perl, circular dependencies are heavily used.
[...]
But this seems to bring problems, see the comments in https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7
Is this just a bug in yum, or is there a problem on my side?
I would argue it is a bug in yum indeed - it says "foo is not available" for various foos that clearly actually _are_ available.
But IIRC similar cases (monolithic package split to several subpackages) have been successfully worked around in the past by adding "Obsoletes: $monolithic_package < $first_nonmonolithic_package_evr" to all those new subpackages. Based on the perl package changelog, I suppose for this case it could be something like "Obsoletes: perl-devel < 4:5.8.8-20" for subpackages that perl-devel used to pull in but no longer does.
Having said that, in case you're planning to push the all-the-way split perl package to F-7 as an update: FWIW in my opinion it is a pretty intrusive one to be pushed at this point. I think not even all packages in Rawhide have been verified to build and work properly with the split done all the way and transition-time dependencies dropped.
Hello,
On Tue, Aug 21, 2007 at 01:14:37PM +0300, Ville Skyttä wrote:
Having said that, in case you're planning to push the all-the-way split perl package to F-7 as an update: FWIW in my opinion it is a pretty intrusive one to be pushed at this point.
The "all-the-way split perl package" was part of the original Fedora 7 release.
The updates for F-7 contain only small changes. I guess that the yum bug might have been triggered by perl rpms even if they were identical to the previous release.
Let's see if -23.fc7 gets any complaints.
In any case, I'm going to push the package to updates after a week in testing or so, unless a bug is discovered in it.
Have a nice day, Stepan Kasal
On Tuesday 21 August 2007, Stepan Kasal wrote:
Hello,
On Tue, Aug 21, 2007 at 01:14:37PM +0300, Ville Skyttä wrote:
Having said that, in case you're planning to push the all-the-way split perl package to F-7 as an update: FWIW in my opinion it is a pretty intrusive one to be pushed at this point.
The "all-the-way split perl package" was part of the original Fedora 7 release.
That's not what I mean by "all-the-way split". perl-devel in F7 has these artificial/transitional dependencies which have been removed in Rawhide (which is what I mean by all-the-way):
Requires: perl(CPAN), perl(ExtUtils::Embed), perl(ExtUtils::MakeMaker) Requires: perl(Test::Harness), perl(Test::Simple)
But I see that -23 in F-7 still has these, so looks like the update isn't what I thought it'd be and so my FWIW opinion above can be ignored.
Hi,
On Tue, Aug 21, 2007 at 02:22:52PM +0300, Ville Skyttä wrote:
That's not what I mean by "all-the-way split". perl-devel in F7 has these artificial/transitional dependencies which have been removed in Rawhide (which is what I mean by all-the-way):
Requires: perl(CPAN), perl(ExtUtils::Embed), perl(ExtUtils::MakeMaker) Requires: perl(Test::Harness), perl(Test::Simple)
oh, thanks for the clarification.
And thanks for the hint, too. I was thinking about those requires today. But after your warning, I'll remember not to remove them.
BTW: perl(ExtUtils::Embed) and perl(ExtUtils::MakeMaker) are generated anyway, because of the scripts in perl-devel, so the artificial part is: Requires: perl(CPAN), perl(Test::Harness), perl(Test::Simple)
Stepan
Stepan Kasal wrote:
in perl, circular dependencies are heavily used.
First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem
<tangent> I've never understand why one would ever split packages, but them depend on each other. What's the point? What advantage does that have over simply having the contents of both (sub)packages in a single package? </tangent>
-- Rex
Hello,
On Tue, Aug 21, 2007 at 02:13:55PM -0500, Rex Dieter wrote:
Stepan Kasal wrote:
First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem
<tangent> I've never understand why one would ever split packages, but them depend on each other. What's the point? What advantage does that have over simply having the contents of both (sub)packages in a single package? </tangent>
with foo and foo-libs, foo-libs can be declared multilib. So it is possible that on x86_64 both foo-libs.i386 and foo-libs.x86_64 are installed.
If both formed one package "foo" and the usage of the libraries in both 32bit and 64bit variant were required, then the package foo would have to be declared as multilib.
The files which are outside {/usr,}/lib{,64} may cause a collision. For ELF files, rpm selects one of the two, but all other collisions have to be resolved: every generated file has to be snitized, so that it is identical for both architectures.
That might be very tedious, and thus the split.
Hope this explains it, Stepan Kasal
Stepan Kasal wrote:
Hello,
On Tue, Aug 21, 2007 at 02:13:55PM -0500, Rex Dieter wrote:
Stepan Kasal wrote:
First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem
<tangent> I've never understand why one would ever split packages, but them depend on each other. What's the point? What advantage does that have over simply having the contents of both (sub)packages in a single package? </tangent>
with foo and foo-libs, foo-libs can be declared multilib. So it is possible that on x86_64 both foo-libs.i386 and foo-libs.x86_64 are installed.
If both formed one package "foo" and the usage of the libraries in both 32bit and 64bit variant were required, then the package foo would have to be declared as multilib.
Um, but if <foo>-libs Requires: foo , wouldn't that pull foo into the multilib mix too, no? Am I missing something?
-- Rex
On Tue, 21 Aug 2007 14:33:53 -0500 Rex Dieter rdieter@math.unl.edu wrote:
Stepan Kasal wrote:
Hello,
On Tue, Aug 21, 2007 at 02:13:55PM -0500, Rex Dieter wrote:
Stepan Kasal wrote:
First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem
<tangent> I've never understand why one would ever split packages, but them depend on each other. What's the point? What advantage does that have over simply having the contents of both (sub)packages in a single package? </tangent>
with foo and foo-libs, foo-libs can be declared multilib. So it is possible that on x86_64 both foo-libs.i386 and foo-libs.x86_64 are installed.
If both formed one package "foo" and the usage of the libraries in both 32bit and 64bit variant were required, then the package foo would have to be declared as multilib.
Um, but if <foo>-libs Requires: foo , wouldn't that pull foo into the multilib mix too, no? Am I missing something?
foo-libs.i386 and foo-libs.x86_64 can both depend on foo.x86_64, can't they?
Paul.
On Tue, 21 Aug 2007 14:33:53 -0500 Rex Dieter rdieter@math.unl.edu wrote:
Um, but if <foo>-libs Requires: foo , wouldn't that pull foo into the multilib mix too, no? Am I missing something?
No, as "foo" is arch independent. The idea here is that foo-devel has a .so symlink that points to an arch specific library. If that library is in a -libs package then only the -libs package from the secondary arch is brought in, and the Requires foo is satisfied by the single arch foo.
Jesse Keating wrote:
On Tue, 21 Aug 2007 14:33:53 -0500 Rex Dieter rdieter@math.unl.edu wrote:
Um, but if <foo>-libs Requires: foo , wouldn't that pull foo into the multilib mix too, no? Am I missing something?
No, as "foo" is arch independent. The idea here is that foo-devel has a .so symlink that points to an arch specific library.
So a -devel's Requires: %{name} ... is treated differently (is arch specific) than a -libs's Requires: %{name} ... (which isn't?)
or is there some implicit requires in -devel's lib*.so symlink (which doesn't show in 'rpm --requires' or 'rpm --provides')?
-- Rex
On Tue, 21 Aug 2007 22:43:55 -0500 Rex Dieter rdieter@math.unl.edu wrote:
So a -devel's Requires: %{name} ... is treated differently (is arch specific) than a -libs's Requires: %{name} ... (which isn't?)
or is there some implicit requires in -devel's lib*.so symlink (which doesn't show in 'rpm --requires' or 'rpm --provides')?
It's a require that is generated at build time by following where the .so symlink points to and requiring that library file.
$ rpm -qp --requires /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm warning: /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1 <snip>
$ rpm -qp --requires /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm warning: /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1()(64bit) <snip>
See how one is the non arch specific liblockdev.so.1 and the other is arch specific? ockdev.so.1' and the only thing that provides that is the i386 build. Likewise the only thing providing the liblockdev.so.1()(64bit) is the x86_64 build of it.
-- Jesse Keating Fedora -- All my bits are free, are yours?
Jesse Keating wrote:
or is there some implicit requires in -devel's lib*.so symlink (which doesn't show in 'rpm --requires' or 'rpm --provides')?
It's a require that is generated at build time by following where the .so symlink points to and requiring that library file.
$ rpm -qp --requires /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm warning: /srv/pungi/dev21.3/7.90/Fedora/i386/os/Fedora/lockdev-devel-1.0.1-11.fc7.i386.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1 <snip>
$ rpm -qp --requires /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm warning: /srv/pungi/cache/lockdev-devel-1.0.1-11.fc7.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 liblockdev.so.1()(64bit)
<snip>
See how one is the non arch specific liblockdev.so.1 and the other is arch specific? ockdev.so.1' and the only thing that provides that is the i386 build. Likewise the only thing providing the liblockdev.so.1()(64bit) is the x86_64 build of it.
Thanks Jessie, I think I've got my brain wrapped around this now.
-- Rex
packaging@lists.fedoraproject.org