Bug#230308: Notify interested packages of major perl upgrades with a trigger

[Dominic Hargreaves]

On Fri, May 23, 2008 at 03:45:08PM +0300, Niko Tyni wrote:
> On Fri, May 23, 2008 at 09:03:16AM +0200, Raphael Hertzog wrote:
> > On Thu, 22 May 2008, Niko Tyni wrote:
> > > Both of the schemes have the partial upgrade problem: they need
> > > co-operation from spamassassin (and the hypothethical other packages)
> > > and won't work if perl is upgraded but spamassassin is held at the old
> > > version that doesn't co-operate yet. Then again, nothing would except
> > > explicitly listing the packages in the perl postinst.
> > 
> > Both solution should work provided that the unpack of the upgraded
> > spamassassin happens before the configuration of the new perl. But there's
> > no guaranty that this will be the case indeed.
> 
> Hm, the case where perl and spamassassin are upgraded in the same go is
> actually not interesting: spamassassin uses dh_installinit and will thus
> stop itself in the prerm and start again in the postinst (at which point
> the new perl is guaranteed to be configured because of the dependencies.)
> 
> So this bug only applies to partial upgrades. 
> 
> Looks like we're left with 
> 
> - the libc6 style solution that's a lot of work in the perl package
>   (done properly, it should ask for permission first via debconf
>    before fiddling with another package just like libc6 does)
> 
> - two easy solutions which will work only if spamassassin is upgraded
>   first and perl afterwards, not vice versa.
> 
> What's more, the spamassassin in sid Depends on perl-modules (>= 5.10),
> so the libc6 style solution is the only one that would actually ever be
> activated and the whole discussion just turned academic. Bah.
> 
> I suppose we could still codify that perl will activate a trigger on
> major upgrades, so packages could rely on that for the next transition...

If we still think that this is a good idea, then now is probably a good
time to start thinking about it.

As far as I can see, this is actually pretty simple, and there is a
working prototype in

<http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;filename=trigger-test.log;att=1;bug=230308>

As for naming the trigger, would "perl-major-upgrade" do? (the
documentation at /usr/share/doc/dpkg-dev/triggers.txt.gz is fairly
flexible about naming).

We should perhaps discuss this a bit more widely on debian-devel before
implementation, as suggested by triggers.txt. I suppose that the
documentation for the functionality should be put into the Debian
Perl policy, so perhaps including debian-policy in discussion would
also be useful.

This doesn't need to block transition of perl 5.12 to unstable, but it
would make sense to get this feature into perl early in the development
cycle of wheezy so that it may be useful during upgrades between squeeze
and wheezy.

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)