Re: Perl Policy change to document major version upgrade trigger
Dominic Hargreaves wrote:
> A not-so-recent bug report, #230308, raised the issue of how a long-running
> program which would be broken (until restart) by a major Perl package upgrade
> (eg from 5.10 to 5.12) could be notified of such a restart. There was a rough
> consensus on that bug report that, once triggers were available, they could
> be used as means to this end, as proposed on that bug report.
Thanks, Dominic. Cc-ing debian-perl for seconds and other thoughts.
> As such, perl 5.12.3-2, currently in experimental, implements the perl
> half of this fix, by triggering the perl-major-upgrade trigger if it is
> upgraded from a version older than 5.12.0. I've tested this against a
> modification of the spamassassin package which implements the receiving
> side of the proposal, with success. The implementation is for all
> practical purposes identical to the proof of concept posted by Niko to
> the original bug.
> My proposed modification to the Perl policy is a new section entitled
> "Upgrades", attached as a patch against git.
Signed-off-by: Dominic Hargreaves <email@example.com>
perl-policy.sgml | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/perl-policy.sgml b/perl-policy.sgml
index b9f3277..47cf9f6 100644
@@ -461,6 +461,26 @@ perl -MExtUtils::Embed -e ldopts
package must depend upon it explicitly.
+ <sect id="perl_upgrades">
+ <heading>Perl Package Upgrades</heading>
+ Starting from <package>perl</package> 5.12.3-2, a dpkg trigger
+ named <var>perl-major-upgrade</var> will be triggered by the
+ postinst of the <package>perl</package> package during major
+ upgrades. Some examples of things which consitute a major upgrade
+ are an upgrade which would change the value of versioned
+ directories in <tt>@INC</tt>, or one which changes <tt>abiname</tt>.
+ Any package may declare an interest in the trigger, especially
+ packages including long-running daemons which would stop working
+ until restart.
+ It is suggested that such packages include an appropriate section
+ in their postinst to handle the trigger by restarting relevant
+ daemons or notifying users of further action.