perl DateTime packaging question

[David Mansfield]

On Tue, 2008-05-27 at 23:49 +0200, Patrice Dumas wrote:
> On Tue, May 27, 2008 at 04:41:23PM -0500, Jason L Tibbitts III wrote:
> > >>>>> "PD" == Patrice Dumas <pertusus at free.fr> writes:
> > 
> > PD> It is, although shipping different packages in one (with different
> > PD> release schedules, tarballs, authors etc.) is bad
> > PD> practice. Normally this is raised during reviews, but not here.
> > 
> > Well, this was explained in the review ticket:
> >   https://bugzilla.redhat.com/show_bug.cgi?id=167376
> > 
> > "This package is a bit odd.  To avoid circular dependencies, I've
> >  bundled DateTime, DateTime::Locale, and DateTime::TimeZone."
> > 
> > I'm not sure of the best way to avoid those circular dependencies, but
> > surely bundling a few closely related and very small modules is low on
> > the hierarchy of packaging sins.
> 
> I think that it is perfectly right, in fact.
> 
> > PD> I suggest that you open a bug against perl-DateTime.
> > 
> > Not sure what good it would do, given the above.
> 
> Indeed, sorry, I missed the explanation.
> 

Problem is, the explanation is a bit bunk.  The reason I'm even here is
because I'm getting the package via EPEL, and it conflicts with the
DAG/rpmforge packaging, which does use three separate packages (quite
successfully - I've been living with DAG/rpmforge for years happily, and
only recently got into the EPEL business). 

So the question is: is there a 'yummy' way to make a package which
bundles all three perl CPAN tarballs 'Obsolete' one which is packaged as
three separate ones...  and vice-versa I suppose.

I'm trying to find a way to make DAG/rpmforge and EPEL play nice (for
perl-DateTime).

Any ideas?

Thanks,
David