[Pkg-alsa-devel] Bug#106244: #106244

[David B Harris]

On Sat, 28 Feb 2004 11:04:27 +0100
Thomas Hood <jdthood@yahoo.co.uk> wrote:
> > The problem I see with doing it in the preinst is as follows:
> > 
> > 1. alsa-utils preinst runs, moves asound.state to /var
> > 2. alsa-driver old postrm runs /etc/init.d/alsa stop, state gets stored
> >    to /etc (the old alsactl is still on-disk)
> > 3. alsa-utils finishes unpacking
> > 4. alsa-driver new postinst runs /etc/init.d/alsa start, mixer settings
> >    are restored from /var
> 
> This will not happen because the sequence would be
> 
> 1. alsa-utils new-preinst upgrade oldver -- moves asound.state to /var
> 2. alsa-utils and alsa-base are unpacked
> 3. alsa-base old-postrm upgrade newver -- possibly does "alsactl store"
>    alsa-utils old-postrm upgrade newver
> 4. alsa-base new-postinst configure oldver -- possibly "alsactl restore"
>    alsa-utils new-postinst configure oldver
> 
> I assume here that alsa-base and alsa-utils are upgrade simultaneously.

I've just done some testing, and dpkg will happily run the alsa-base's
old-postrm without the new alsactl's preinst being run. Perhaps it won't
happen if they're upgraded simulatenously in the same apt run, but we
shouldn't rely on that.

That being said, what are the advantages to moving it in alsactl's
preinst? Maybe if it's worth it....