Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227822 - BuildRequires: perl-XML-Parser
Summary: BuildRequires: perl-XML-Parser
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: beryl-plugins
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-08 13:12 UTC by Ralf Corsepius
Modified: 2013-01-10 04:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-02-08 15:52:08 UTC


Attachments (Terms of Use)

Description Ralf Corsepius 2007-02-08 13:12:19 UTC
Description of problem: - A Packaging bug:

Your spec contains this:
..
BuildRequires:  perl-XML-Parser, gettext-devel, libjpeg-devel
..

The should be 
BuildRequires: perl(XML::Parser)

Version-Release number of selected component (if applicable):

0.1.9999.1-1

Comment 1 Jarod Wilson 2007-02-08 15:52:08 UTC
I'm not seeing this explicitly called out the in packaging guidelines. Am I just
missing it? Just the same, I've updated my local tree accordingly (for all beryl
bits I've got that have a BR on perl-XML-Parser), since its a bit more
future-proof. I won't bother with rebuilding until the next beryl release though
(but that's any day now).

Comment 2 Ralf Corsepius 2007-02-08 16:08:23 UTC
(In reply to comment #1)
> I'm not seeing this explicitly called out the in packaging guidelines. Am I just
> missing it?
It's such kind of elementary perl-packaging knowledge, I am surprised having to
explain it.

> Just the same, I've updated my local tree accordingly (for all beryl
> bits I've got that have a BR on perl-XML-Parser), since its a bit more
> future-proof.
That's the mistake. 

perl(XML::Parser) means the perl-module, the program "perl" searches for on its
internal search path. 

perl-XML-Parser is a package name, which is by no means related to the perl
module XML::Parser (rpm syntax: perl(XML::Parser)), except that the perl module
XML::Parser currently is contained inside of the perl-XML-Parser package. 

It could be anywhere else (e.g. the perl base package, or some other arbitarily
named package).

> I won't bother with rebuilding until the next beryl release though
> (but that's any day now).


Comment 3 Jarod Wilson 2007-02-08 16:22:46 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I'm not seeing this explicitly called out the in packaging guidelines. Am I just
> > missing it?
> It's such kind of elementary perl-packaging knowledge, I am surprised having to
> explain it.

I touch perl as little as possible.

> > Just the same, I've updated my local tree accordingly (for all beryl
> > bits I've got that have a BR on perl-XML-Parser), since its a bit more
> > future-proof.
> That's the mistake. 
> 
> perl(XML::Parser) means the perl-module, the program "perl" searches for on its
> internal search path. 

Unless I'm off my rocker, that's not exactly applicable in this case.
BuildRequires: perl(XML::Parser) just means I need to find a package that
Provides: perl(XML::Parser) to satisfy the build requirement. Its not actually
searching for the module...

$ rpm -q --provides perl-XML-Parser
[...]
perl(XML::Parser) = 2.34
[...]

> perl-XML-Parser is a package name, which is by no means related to the perl
> module XML::Parser (rpm syntax: perl(XML::Parser)), except that the perl module
> XML::Parser currently is contained inside of the perl-XML-Parser package. 
> 
> It could be anywhere else (e.g. the perl base package, or some other arbitarily
> named package).

Please forgive my limited knowledge of perl packaging, but aren't the bulk of
perl-Foo-Bar packages named as such explicitly because they provide
perl(Foo:Bar)? The only real risk I see here with BR: perl-XML-Parser is if
perl(XML::Parser) moves into another package and perl-XML-Parser ceases to exist.

Regardless, I've already made the change on my end.

Comment 4 Ralf Corsepius 2007-02-08 16:50:57 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)

> > > Just the same, I've updated my local tree accordingly (for all beryl
> > > bits I've got that have a BR on perl-XML-Parser), since its a bit more
> > > future-proof.
> > That's the mistake. 
> > 
> > perl(XML::Parser) means the perl-module, the program "perl" searches for on its
> > internal search path. 
> 
> Unless I'm off my rocker,
You are ;)

>  that's not exactly applicable in this case.
> BuildRequires: perl(XML::Parser) just means I need to find a package that
> Provides: perl(XML::Parser) to satisfy the build requirement.
Nope, 
BuildRequires: perl(XML::Parser)
means your package somewhere inside of a perl-script uses XML::Parser.

It probably contains a fragment like this:
use XML::Parser

This perlsyntax refers to the perl module XML::Parser, being searched on perl's
search path.

> Its not actually
> searching for the module...
>
> $ rpm -q --provides perl-XML-Parser
> [...]
> perl(XML::Parser) = 2.34
> [...]
Exactly, the package perl-XML-Parser provides this module.

More accurately it is this file (perl modules map 1:1 to files):
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/XML/Parser.pm

> Please forgive my limited knowledge of perl packaging, but aren't the bulk of
> perl-Foo-Bar packages named as such explicitly because they provide
> perl(Foo:Bar)?
No. The name perl-Foo-Bar corresponds to a CPAN "distribution" (a source
tarball) called Foo-Bar.

Most CPAN "distributions" named "Foo-Bar" also contain the file .../Foo/Bar.pm
and therefore cause rpm to emit perl(Foo::Bar) but this also is a random accident.

Also noteworthy is the difference between the version attached to
perl-Foo-Bar and perl(Foo::Bar)
perl-Foo-Bar carries the version of the tarball
perl(Foo::Bar) the verion of the perl module
Both do not necessarily have to be identical.

perl-Foo-Bar-1.0 can provide 
perl(Foo::Bar) = 1.23

It can even simulaneously provide 
perl(Foo::Bar::Baz) = 0.5009


The differences are similar to SONAMEs for shared libs.
package XYZ-1.0.tar.gz can provide libxyz.so.1.2.3 (on ld.so's default search path)

Comment 5 Jarod Wilson 2007-02-08 17:48:01 UTC
(In reply to comment #4)
> > > perl(XML::Parser) means the perl-module, the program "perl" searches for
on its
> > > internal search path. 
> > 
> > Unless I'm off my rocker,
> You are ;)

Nah, I think we're just looking at this from different points of view...

> >  that's not exactly applicable in this case.
> > BuildRequires: perl(XML::Parser) just means I need to find a package that
> > Provides: perl(XML::Parser) to satisfy the build requirement.
> Nope, 
> BuildRequires: perl(XML::Parser)
> means your package somewhere inside of a perl-script uses XML::Parser.
> 
> It probably contains a fragment like this:
> use XML::Parser
> 
> This perlsyntax refers to the perl module XML::Parser, being searched on perl's
> search path.

What I meant to say is that the process of collecting up BuildRequires: doesn't
actually look for a perl module to execute, it looks for the package that
Provides: the bits you've listed as BuildRequires:. It assumes you've given it
proper BR:, it doesn't actually *look* inside the package that Provides: the
bits to verify the perl module really is there until we actually start building.

> > Its not actually
> > searching for the module...
> >
> > $ rpm -q --provides perl-XML-Parser
> > [...]
> > perl(XML::Parser) = 2.34
> > [...]
> Exactly, the package perl-XML-Parser provides this module.
> 
> More accurately it is this file (perl modules map 1:1 to files):
> /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/XML/Parser.pm
> 
> > Please forgive my limited knowledge of perl packaging, but aren't the bulk of
> > perl-Foo-Bar packages named as such explicitly because they provide
> > perl(Foo:Bar)?
> No. The name perl-Foo-Bar corresponds to a CPAN "distribution" (a source
> tarball) called Foo-Bar.

Ah, true. But then, as you say, Foo-Bar does typically contain .../Foo/Bar.pm...

> Most CPAN "distributions" named "Foo-Bar" also contain the file .../Foo/Bar.pm
> and therefore cause rpm to emit perl(Foo::Bar) but this also is a random accident.

and to me, it doesn't seem all that random or accidental to me with soooo many
perl-X-Y packages that contain perl module .../X/Y.pm...

> Also noteworthy is the difference between the version attached to
> perl-Foo-Bar and perl(Foo::Bar)
> perl-Foo-Bar carries the version of the tarball
> perl(Foo::Bar) the verion of the perl module
> Both do not necessarily have to be identical.
> 
> perl-Foo-Bar-1.0 can provide 
> perl(Foo::Bar) = 1.23
> 
> It can even simulaneously provide 
> perl(Foo::Bar::Baz) = 0.5009
> 
> 
> The differences are similar to SONAMEs for shared libs.
> package XYZ-1.0.tar.gz can provide libxyz.so.1.2.3 (on ld.so's default search
path)

Duly noted. I hadn't meant to bring versioning into it at all, the dep isn't at
all version. But that does illustrate to me further evidence of why a dep on the
module is better, since that's a more likely spot where you may need a >=
versioned dep.


Comment 6 Ralf Corsepius 2007-02-08 18:11:55 UTC
(In reply to comment #5)
> (In reply to comment #4)

> Ah, true. But then, as you say, Foo-Bar does typically contain .../Foo/Bar.pm...
> 
> > Most CPAN "distributions" named "Foo-Bar" also contain the file .../Foo/Bar.pm
> > and therefore cause rpm to emit perl(Foo::Bar) but this also is a random
accident.
> 
> and to me, it doesn't seem all that random or accidental to me with soooo many
> perl-X-Y packages that contain perl module .../X/Y.pm...

No, what you see is the "standard" scheme being applied by perl "dists", being
applied by many dists, but not by all. Generally speaking, this is nothing but a
random accident/random coincidence.

A classical situation, where the difference shows, is when a separate
perl-dist requires a greater version of a perl-module that RH ships as part of
their base perl package.

You then see building a perl-package break and bomb out while building 
due to insufficent perl-modules versions,
despite all "BuildRequires: on packages" are met.

Cf. rpm -q --provides perl
and check for the versions attached to perl(..)


Another example is this package.
# rpm -q --provides -p perl-gettext-1.05-9.i386.rpm 
gettext.so  
perl(Locale::gettext) = 1.05
perl-gettext = 1.05-9

Note: the name of the perl-dist is "gettext", but the module it provides is
Locale::gettext

Comment 7 Jarod Wilson 2007-02-08 20:38:51 UTC
Thank you for the education, I now know way more about the ins and outs of perl
packages than I ever really wanted to. :)


Note You need to log in before you can comment on or make changes to this bug.