Fwd: rpms/perl/devel perl.spec,1.246,1.247

[Chris Weyl]

On Fri, Dec 18, 2009 at 9:14 PM, Tom "spot" Callaway
<tcallawa at redhat.com> wrote:
> On 12/19/2009 12:07 AM, Ralf Corsepius wrote:
>>> Also...  Even if we exclude these modules w/o providing them as
>>> sub-packages, we ought to ensure that they're still pulled in by
>>> perl-core (and perl itself, when we make the
>>> perl-core/perl/perl-minimal switch).
>>
>> What you say doesn't make sense:
>>
>> 1) They are provided as separate modules, by
>> a) CPAN
>> b) Fedora packages.
>
> Yes, but 1a has always been true, and 1b has been true in the past.
> We've generally opted to keep the bundled "core" modules as part of the
> main perl package to keep user and developer expectations sane.
>
> If the point is that the base perl modules get outdated, well, we've
> successfully patched those modules forward when there is a good reason
> to do so.

I've done that a myself; it's a bit of a process but the wiki pages
are quite helpful in showing how to do it in a clean, consistent way.
The source tree restructuring that's currently going on will help make
this easier as we go on (making the structure closer to that of the
equivalent CPAN tarball, if memory serves).

Ralf, I hear what you're saying here but it's incontrovertible that
upstream has chosen a set of CPAN dists and blessed them as core.  If
there's a good reason for an update of a core module at a distribution
level, there are several of us willing to create the patches and
update the package after the request is vetted; failing that groups
can still build standalone packages that upgrade a subpackage.  My
starting this thread was not a complete rejection of your changes --
as an emergency fix I believe they were reasonable -- but going
forward I thought we could benefit from a discussion before we
departed from current practice.

>> 2) Since introducing the package split to "perl", package deps on
>> perl-packages in general don't make any sense anymore. It's the reason
>> why we are enforcing BR: perl(xxx).
>
> Yes, but perl upstream chose which modules to include with "perl core".
> If we decide not to package a module, instead deferring to the separated
> package, we should make sure that the separated package gets installed
> if someone installs the perl-core metapackage. The way to do that is to
> add the hardcoded Requires.

Yep -- this is a main/sub package dependency we're dealing with; even
if, say, someone wanted to install a higher-versioned perl-parent the
dep in the main package would still be satisfied, as it is
unversioned.  The phrase "exception that proves the rule" comes to
mind here :)

                                     -Chris
-- 
Chris Weyl
Ex astris, scientia