On Fri, Jun 26, 2009 at 12:53 PM, Yanko Kaneti
<yaneti@declera.com> wrote:
On Fri, 2009-06-26 at 11:08 -0700, Chris Weyl wrote:
> What Ralf is rather vigorously saying is that both by convention and
> explicit guideline, due to the fluid nature of perl-* packages they're
> supposed to own everything they provide under %{perl_vendorarch} or
> %{perl_vendorlib}. Specifying ownership of a subset of that is
> considered a blocker at review and a packaging bug post-review...
> It's just a packging issue, it has nothing to do with the relationship
> between DBIC and DBIC::DynamicDefault.
>
I gotta say tho, whats written in the guidelines is not nearly explicit
enough to convey the message.
"there are several instances where it's desirable for multiple packages
to own a directory" desirable, really....
"perl packages are permitted to share ownership of directories."
permitted, how nice.
Its rather counter intuitive to the way that almost anything else works.
Unless there is a bold "must" somewhere there, and perhaps a rpmlint
warning I think this will come back again and again.
As it is right now :) (What is it the Cylons say? All this has happened before, and all this will happen again?)
You're right in that It's not a listed as a must, but a should... Even though it is enforced as a must through reviews and packaging bugs. It all basically boils down to that a package providing "perl(DBIx::Class)" doesn't actually tell you exactly where DBIx/Class.pm is located, only that it's somewhere under @INC.
There's actually a few things I'd like rpmlint to catch -- like, say, provides being issued for shared libs not in traditional "system paths" (/usr/lib, etc) -- but I'm not holding my breath for it.