On Wed, Dec 07, 2011 at 11:41:31AM +0000, Dave Howorth wrote:

As far as I can see, that's an RPM packaging error rather than a perl packaging error, yes? In which case I can't help, and all I can suggest is one or all of: (1) poke around the RPM files and see what is going on (2) check perl -V returns what you expect and that installing IO::Compress from CPAN works (you can always delete it later) (3) if nobody else replies, try reposting to this list with RPM or zypper in the subject instead of perl

As perl-IO-Compress is nowadays a part of core perl, you mustn't install it. Despite of the name, it *doesn't* provide perl(IO::Compress), so it wouldn't help you anyways. (An IO::Compress perl module doesn't seem to exist.) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Craig Millar wrote:

Hmm, I am getting something similar, with the devel:languages:perl repo enabled:

I downloaded the perl-Compress-Raw-Zlib rpm and tried to install directly with rpm and got an error:

error: Failed dependencies: perl-Compress-Raw-Zlib is obsoleted by (installed) perl-5.14.2-1.9.i586

I don't really have an answer I'm afraid, it appears to be something to do with inconsistent packages in devel:languages:perl and you may want to try CPAN as suggested by Dave if you can't wait for it to be fixed.

Hmm, that suggests that it's already installed and http://perldoc.perl.org/index-modules-C.html indicates that Compress::Raw::Zlib is a core module, so doesn't need to be installed. http://perldoc.perl.org/index-modules-I.html indicates that at least some parts of IO::Compress are core modules. Have either of you tried just running perl programs that use these modules? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wednesday 07 December 2011 09:01:05 Greg Freemyer wrote:

I think the real issue is this line from the perl specfile:

Provides: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Obsoletes: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib

Note the absence of perl-IO-Compress. I can branch perl in OBS and add perl-IO-Compress easily enough, but I don't think I know enough about perl to test it outside of the one package I'm testing that uses it.

I just asked on the -packaging list if adding perl-IO-Compress to the above makes sense. If I get buy-in and that fixes the issue for me, I'll SR an update to D:L:P::perl

Let me know if you agree.

The correct answer is "I don't know". I doubt the above could cause a dependency error on "perl = 5.14.2" though. What you found might be a problem, I'm not sure, but I'd be greatly surprised if it's the root cause of the bug you reported Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

I think the real issue is this line from the perl specfile:

Provides: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Obsoletes: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib

Note the absence of perl-IO-Compress. I can branch perl in OBS and add perl-IO-Compress easily enough, but I don't think I know enough about perl to test it outside of the one package I'm testing that uses it.

Greg, I believe *you are in a pit. Please stop digging it deeper!* IO::Zlib and IO::Compress::Base are core modules since Perl 5.10.0. They should be in the core perl package and indeed when I ask on an 11.2 system, YaST tells me IO::Zlib is part of the standard package 'perl'. What happens if you just run the application? So there should be absolutely no need to install these packages from a separate source. Which suggests that the package hasn't been properly prepared and perhaps similarly for whatever this application is. Have they been updated since 11.1? Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

I'm trying to package up something new. The release notes I think said it needed IO::Compress, so I possibly naively just put it in the specfile as a Requires.

So I'm digging deep so I get it right. Then I will push it to factory eventually.

The way to get it right is to take a blank machine and install whatever opensuse release you want. Then install perl, if it isn't automatic. Then load the application and try to run it. Look at the output and use the error messages to tell you what modules it needs. Install those. Check the application runs. By all means then check with the release notes :) Then start writing a spec file and making an RPM. Then take a blank machine and install whatever opensuse release you want. Then install perl, if it isn't automatic. Then install the application RPM. Check the application runs. JMHO. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

I'm not a perl expert. The theory is you should not have to be an expert in a language to package up a app written in it.

Hmm, I'm not sure where that theory comes from but I don't believe it :)

I "think" with perl, the "use" statements can be anywhere in the code.

Yes, pretty much.

When one of those is hit, the module in question is loaded.

No. The module is unconditionally loaded before the program runs, during compilation. For the behaviour you describe, use the 'require' function, or 'do' or 'eval'. Remember that for Perl, TMTOWTDI.

So to do as you suggest would required exercising every code path that has a "use" statement in it. That is not necessarily very effective.

There are perl tools to discover such dependencies (pp -c, pp -x etc).

Further, since I don't know perl very well, I don't know what other mechanisms would cause a module to be loaded.

So, I'm reversing your process. Create what I believe to be a good specfile by reading release notes and code, then try to run it and and any Requires that I come across.

Right, but since I don't believe the premise, I don't think it's safe to draw the conclusion that this is a good idea. :) Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Wed, 07 Dec 2011, Dave Howorth wrote:

Greg Freemyer wrote:

...

I think the real issue is this line from the perl specfile:

Provides: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Obsoletes: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib [..] I believe *you are in a pit. Please stop digging it deeper!*

Stop digging yourself ;)

IO::Zlib and IO::Compress::Base are core modules since Perl 5.10.0.

CPAN disagrees. cpan[2]> m IO::Compress::Base Module id = IO::Compress::Base CPAN_USERID PMQS (Paul Marquess ) CPAN_VERSION 2.045 CPAN_FILE P/PM/PMQS/IO-Compress-2.045.tar.gz MANPAGE IO::Compress::Base - Base Class for IO::Compress modules INST_FILE /usr/lib/perl5/vendor_perl/5.12.3/IO/Compress/Base.pm ^^^^^^^^^^^ that's d:l:p, not the perl.rpm INST_VERSION 2.036 cpan[3]> m IO::Zlib Module id = IO::Zlib DESCRIPTION IO:: style interface to Compress::Zlib CPAN_USERID TOMHUGHES (Tom Hughes ) CPAN_VERSION 1.10 CPAN_FILE T/TO/TOMHUGHES/IO-Zlib-1.10.tar.gz DSLIP_STATUS bdpO? (beta,developer,perl,object-oriented,) MANPAGE IO::Zlib - IO:: style interface to LCompress::Zlib INST_FILE /usr/lib/perl5/5.12.3/IO/Zlib.pm INST_VERSION 1.10 If they were core-modules, they'd have the perl-tarball as CPAN_FILE, compare: cpan[4]> m B::Deparse Module id = B::Deparse CPAN_USERID JESSE (Jesse Vincent ) CPAN_VERSION 1.08 CPAN_FILE F/FL/FLORA/perl-5.15.4.tar.gz MANPAGE B::Deparse - Perl compiler backend to produce perl code INST_FILE /usr/lib/perl5/5.12.3/B/Deparse.pm INST_VERSION 0.9701 That openSUSE packages those in the perl-RPM is completely irrelevant, they are maintained as seperate modules by seperate people outside of perl-core. IMO, the perl.spec needs versioned Obsoletes: perl($foo) <= $module_version if using any "Obsoletes", the modules from d:l:p use a seperate tree for the files, only the manpages are a real conflict, but those _can_ be overridden in yast/zypper (IIRC), the Obsoletes cannot, I e.g. get only 2 solutions, both identical "do not install $package". That sucks. I resorted to using 'rpm -Uvh --force'. BTW: I'm on 11.4 and it's perl has only IO::Compress 2.024 and I needed >= 2.036. And that a newer Compress::Raw::Zlib. YMMV, -dnh -- In the early days IBM taught that a series of bits transferred together (like so many yoked oxen) formed a Binary Yoked Transfer Element (BYTE). -- Terry Carr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Wed, 07 Dec 2011, Greg Freemyer wrote: [..]

From what I see, your'e right the perl specfile should probably not have any of the explicit Provides statements, and the Obsoletes should be both expanded to cover all of the appropriate packages and they should be version-ed.

Actually: it seems some stuff is also in the perl-tarball, i.e. perl-core pulls in a version "at release" time (comparable to openSUSE pulling in e.g. a certain kernel) and from then on, both go their own paths again. There is e.g. cpan/Compress-Raw-Zlib in the perl-5.14.2 tarball in the d:l:p perl-package, as well as in the upstream tarball (perl.org). There's also the IO::Compress package (cpan/IO-Compress).

Since I'm messing with perl(IO::Compress::*) pretty heavily I don't mind doing a SR to address that for them.

Is there a good syntax that will get the module version easily?

ie. Obsoletes: perl(IO::Compress::Base) < version(perl(IO::Compress::Base)) Obsoletes: perl(IO::Compress::Bzip2) < version(perl(IO::Compress::Bzip2)) etc.

I just tried the above and it fails. I don't want to hard code in version numbers.

As they're completely independent "external" modules integrated into the perl-tarball, they have independent version numbers. You should be able to get at their versions like this (from the unpacked tarball, in the dir ${RPM_BUILD_DIR}/%{name}-%{version} (i.e. perl-5.14.2): ==== for pkg in Compress::Raw::Zlib; do path=$(echo "$pkg" | sed 's,::,/,g') name=$(echo "$pkg" | sed 's,::,-,g') PERL5LIB="./cpan/${name}/lib" \ perl -M${pkg} -e "print qq[${pkg} <= \$${pkg}::VERSION\n];" done ==== That's a bad example though, with non-pure-perl modules you'll likely get an error like: Compress::Raw::Zlib object version 2.045 does not match bootstrap parameter 2.033 at cpan/Compress-Raw-Zlib/lib/Compress/Raw/Zlib.pm line 98. unless the relevant .so is already built (and you'd need to set PERL5LIB to ./cpan/${name}/blib/lib I'd guess (if those modules are build seperately and not from "up tree"). But: "bootstrap parameter 2.033" is the information you want. For IO::Compress, you need a special case, as there's no actual IO::Compress module, the version is in the ::Base module: $ for pkg in IO::Compress; do path=$(echo "$pkg" | sed 's,::,/,g'); name=$(echo "$pkg" | sed 's,::,-,g;'); PERL5LIB="./cpan/${name}/lib" perl -M${pkg}::Base -e "print qq[${pkg} <= \$${pkg}::Base::VERSION\n];"; done IO::Compress <= 2.033 (my in system version is 2.036, so that 2.033 is from the unpacked tarball). You could try to grep for 'VERSION\s*=\s*[\d._]' in the relevant .pm files. And/or the Makefile.PL / Build.PL. I'd help work on that (worst case: one rule for each dir under ./cpan/). But, I'd actually prefer just not having those "Obsoletes:". Argh: "Obsoletes: perl-ExtUtils-ParseXS". IIRC ExtUtils::ParseXS is a highly volatile target, with other modules often requiring recent versions. openSuSE 11.4/perl-5.12.3 comes with 2.21, 12.1/perl-5.14.2 with 2.2210 which I also have in my ~obs Repo for 11.4 and others, cpan has 3.05! And cpan reports: CPAN_FILE S/SM/SMUELLER/ExtUtils-ParseXS-3.05.tar.gz # zypper in 'perl-ExtUtils-ParseXS' Loading repository data... Reading installed packages... Resolving package dependencies... Problem: perl-B-C-1.34-1.x86_64 requires perl(B::Debug), but this requirement cannot be provided uninstallable providers: perl-5.14.2-67.1.i586[home:doiggl] perl-5.14.2-67.1.x86_64[home:doiggl] perl-5.12.3-11.14.1.x86_64[openSUSE-11.4-DVD-x86_64] perl-5.12.3-11.14.1.i586[repo-oss] perl-5.12.3-11.14.1.x86_64[repo-oss] perl-5.12.3-11.16.1.x86_64[repo-update] perl-5.12.3-11.16.1.i586[repo-update] Solution 1: do not install perl-ExtUtils-ParseXS-2.2206-10.1.x86_64 Solution 2: do not install perl-ExtUtils-ParseXS-2.2206-10.1.x86_64 Solution 3: break perl-B-C by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c] (c): That perl-B-C stuff is totally bogus: rpm -q --whatprovides 'perl(B::Debug)' perl-5.12.3-11.18.1.x86_64 Same with Yast, just without the perl-B-C stuff. Anyway, I don't really see a reason for the "Obsoletes" in the .spec, I propose to just drop those. -dnh -- "Amnesia used to be my favorite word, but then I forgot it." -- the BSD fortune file -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org