Re: how to handle newer versions of the modules in perl-modules?
On Thu, May 30, 2002 at 02:01:58PM -0400, Michael Alan Dorman wrote:
>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.
That's what is currently done. perl-modules currently has a short list
of C/R/Ps for modules where earlier versions of modules included were
packaged stand-alone at some point.
Note that "Replaces" isn't strictly required from the perspective of
replacing files due to the @INC layout, but is included in the forlorn
hope that APT will pay attention to §7.5.2 of Debian Policy when
dist-upgrading and remove the offending old module rather than
stubbornly choosing to retain it at the cost of removing a bazillion
packages which depend upon perl.
This list will undoubtably grow over time, and as it stands the
procedure for updating it is manual (and comes principally from bug
reports).
Note that it is only generally a problem when a stand-alone module
becomes included into the core perl distribution however. It is less of
an issue for release upgrades in cases where a module is both in the
core and is [actively] packaged as a stand-alone module since there will
hopefully be a newer version of the stand-alone package available by the
time new perl packages are released.
--bod
--
To UNSUBSCRIBE, email to debian-perl-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: