[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Detecting install vs upgrade in postinst

On Sun, 2016-06-05 at 16:08 +0100, Ian Jackson wrote:
> Ben Hutchings writes ("Detecting install vs upgrade in postinst"):
> > The postinst script for linux-image-* behaves differently on fresh
> > installation vs upgrade.  For a fresh installation, it updates the
> > default symlinks /vmlinuz and /initrd.img to point to the new
> > kernel
> > and initramfs versions.  On upgrade it generally doesn't.
> By the time of the postinst, dpkg no longer has the record of whether
> the unpack was a fresh install, reinstall, or upgrade.

I suspected as much.

> You might be
> able to provide a preinst or prerm which would capture or act on its
> arguments, which differ for upgrades.


> I'm not sure of the rationale behind the behaviour you describe.

The rationale for distinguiushing installation and upgrade is:

- When a kernel package is newly installed, the administrator probably
wants that to be the new default kernel

- When a kernel package is upgraded, the administrator is probably
running a system upgrade and doesn't want the default to change

I think that installation after removal is more like new installation.

> So
> I'm not really happy trying to invent for you a specific scheme.  But
> hopefully you can do that.
> Note that the preinst (and postrm) do not have the package's
> dependencies available.
> > Is there a simple way that a postinst script can tell that the
> > previously configured version was removed?  Or do I have to use some
> > sort of flag file?  (I can imagine either creating this in the preinst,
> > or creating it in postinst and removing it in postrm.)
> As I say, I'm not sure why it's relevant that the
> previously-configured version was removed.

That is the additional information the postinst would need to tell
whether an installation of a previously installed package is an upgrade
or not.


Ben Hutchings
Everything should be made as simple as possible, but not simpler.
                                                           - Albert

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: