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).

(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).

(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.

(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)

(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.

(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

Thank you for the education, I now know way more about the ins and outs of perl
packages than I ever really wanted to. :)