On 6 December 2011 21:17, Greg Freemyer wrote:

I'm trying to install perl-IO-Compress from OBS, but it says I need perl 5.14.2

The strange thing is I have perl 5.14.2, so I'm confused.  If anyone can tell me what's going on, I'd appreciate it.

Hmm, I am getting something similar, with the devel:languages:perl repo enabled: root:~ # zypper in perl-Compress-Raw-Zlib Loading repository data... Reading installed packages... Resolving package dependencies... Problem: perl-Compress-Raw-Zlib-2.045-1.1.i586 requires perl = 5.14.2, but this requirement cannot be provided Solution 1: do not install perl-Compress-Raw-Zlib-2.045-1.1.i586 Solution 2: break perl-Compress-Raw-Zlib by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): c root:~ # rpm -q perl perl-5.14.2-1.9.i586 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. -- 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 Wed, Dec 7, 2011 at 7:11 AM, Anders Johansson wrote:

On Tuesday 06 December 2011 16:17:04 Greg Freemyer wrote:

...

I'm trying to install perl-IO-Compress from OBS, but it says I need perl 5.14.2

The strange thing is I have perl 5.14.2, so I'm confused.  If anyone can tell me what's going on, I'd appreciate it.

===  zypper output that details the above

...

zypper se -s perl-base

Loading repository data... Reading installed packages...

S | Name            | Type    | Version    | Arch   | Repository --+-----------------+---------+------------+--------+------------------ i | perl-base       | package | 5.14.2-1.9 | x86_64 | openSUSE-12.1-OSS v | perl-base       | package | 5.14.2-1.9 | i586   | openSUSE-12.1-OSS

  | perl-base-32bit | package | 5.14.2-1.9 | x86_64 | openSUSE-12.1-OSS

As you can see I have perl 5.14.2 installed from the openSUSE 12.1 main repo

Looks like the problem is that perl provides "perl = 5.14.2-1.9", so the rpm dependency should be >= and not =

Anders

Anders, 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. Thanks Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Dec 7, 2011 at 9:03 AM, Anders Johansson wrote:

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

My true root bug is I'm trying to install a package that has "Requires: perl(IO::Compress)". That failed, so I was trying to install perl-IO-Compress manually to see what was wrong. If perl itself had "Provides: perl(IO::Compress)" my issue would be addressed. Looking at the perl specfile and the earlier link to what's in perl base, the specfile is definitely missing these: Provides: perl(IO::Compress::Bzip2) perl(IO::Compress::Deflate) Provides: perl(IO::Compress::Gzip) perl(IO::Compress::RawDeflate) perl(IO::Compress::Zip) My only question is if it should also have perl(IO::Compress) in the list, or if the other app has an erroneous Requires: perl(IO::Compress). Again, I just asked on -packaging, so I will try to SR up one of the two solutions. Thanks Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

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

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