Re: how to handle newer versions of the modules in perl-modules?

[Michael Alan Dorman <mdorman@debian.org>]

Stephen Zander <gibreel@debian.org> writes:
> Again, no.  lib*-perl packages have *no reason* to interact with
> perl-modules & vice versa.  There are no diversion, no alternatives
> and no 'Conflicts/Repplaces/Depends' required.  It is even possible to
> install modules locally, by hand yourself without fear or trepidation.
> Read the perl policy & become enlightened (a hint: consider the output
> of perl -V).

Well, a strict reading certainly says that there's no need for
interaction because the vendor directories fall first in the search
path, can be common (at least for pure perl modules) between perl
versions, but what should be done when 5.8 comes out, which, until
just a few days ago, looked like it would have a much more advanced
version of Storable included than is in the Debian storable package?

Ideally, that new perl-modules would conflicts/replace/provide
Storable, or do *something* to hint to people that they want to remove
the old storable package to get the benefits of the newer one (since
the vendor one would still be found first in @INC).  And this goes for
all of the modules that are nominally bundled but also maintain a life
outside of the main distribution.

I'll admit that I'm not 100% certain what the best solution
is---though I certainly agree that the loosest possible coupling is
best---but I don't think Ardo's being naive to wonder how best to
handle all this.

Mike.


-- 
To UNSUBSCRIBE, email to debian-perl-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org