Stephen Zander <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
