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

[Ralf Corsepius]

On 12/19/2009 04:29 AM, Chris Weyl wrote:
> Hmm. Sanity check here: are we sure just excluding these is the way we
> want to go?

I certainly think so, otherwise I would not have applied the patches.

Apart of this, my changes we "emergency changes" to get rid of broken 
package deps. Whether these changes shall be kept in long terms is a 
different matter - I certainly want them kept.


> I ask mainly as when we went to 5.10.0 we subsumed the
> newly-cored (dual-lifed, really) modules into the main perl package,
> and obsoleted the standalone packages.   We also have a (more-or-less)
> policy of updating core modules via the main perl package as well.
Yes, it's an ongoing struggle, because with some people prefer to 
enforce monolytic perl packaging and don't seem to want to comprehend 
the advantages module-wise packaging offers.

> I could go either way on this; but I think we should pick an approach
> and stick with it, unless there's compelling reasons otherwise...  And
> the current approach seems to be working well.

Really? I can't avoid to disagree - It doesn't work well at all.

E.g.
* The modules, perl now has absorbed, already exist as separate modules 
with higher versions in Fedora.

* Many modules in "core perl" are outdated.
These are the cause of many issues of rpm interaction with CPAN and are 
the cause of missing dependencies.



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

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


Ralf