Your message dated Sat, 10 Aug 2013 19:21:31 +0200
with message-id <[email protected]>
and subject line Re: Bug#719316: postinst scripts cannot tell whether this is 
the first installation
has caused the Debian Bug report #719316,
regarding postinst scripts cannot tell whether this is the first installation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
719316: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719316
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.16.10
Severity: normal

First of all, we have a workaround for this issue which works well, but
in the future it would be nice to migrate away from that.

Packages that ship a systemd service file (let’s use thinkfan.service as
an example) need to enable that file on the initial installation,
normally by running “systemctl enable thinkfan.service”.

Say the user wants to not start thinkfan on boot, but run it
occasionally on hot summer days. She would use “systemctl disable
thinkfan.service” and run “systemctl start thinkfan.service” when she
actually needs it.

Now, we want to preserve the enabled/disabled state, i.e. on package
upgrades, we do _not_ want to re-enable the file and overwrite the
user’s choice.

The best way to do this is:

1) call systemctl enable on the _initial_ package installation
2) call systemctl disable on purge

The issue is that in postinst, we don’t have the information whether
this is an initial package installation or not (env|grep DPKG in
postinst):

DPKG_MAINTSCRIPT_ARCH=all
DPKG_RUNNING_VERSION=1.16.10
DPKG_MAINTSCRIPT_NAME=postinst
DPKG_MAINTSCRIPT_PACKAGE=kanla
DPKG_ADMINDIR=/var/lib/dpkg
args: configure 1.3-2

Since dpkg knows the package status before performing the requested
operation, can we have the status in an environment variable please?

Let me know if sending a patch will push this forward faster, but I am
not familiar with dpkg’s source at all.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386

Kernel: Linux 3.8.3 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-4
ii  libc6        2.17-2
ii  liblzma5     5.1.1alpha+20120614-2
ii  libselinux1  2.1.13-1
ii  tar          1.26+dfsg-0.1
ii  zlib1g       1:1.2.8.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  0.9.7.7

-- no debconf information

--- End Message ---
--- Begin Message ---
Hi!

On Sat, 2013-08-10 at 18:56:14 +0200, Michael Stapelberg wrote:
> Adam D. Barratt <[email protected]> writes:
> > Apologies if I'm missing something, but why not? From Policy 6.7:
> > 
> >       The `postinst' script may be called in the following ways:
> > 
> >       <postinst> `configure' <most-recently-configured-version>
> >       [...]
> >       If there is no most recently configured version `dpkg' will pass a
> >       null argument.  [1]

> Hm, indeed, that seems to do the trick. Not sure how I have missed that,
> thanks for the hint! :)
> 
> Guillem, are Adam and I missing something here? Checking whether $2 is
> empty seems like an easy way.

Ah, yeah sorry, had forgotten about that; and no, you are not missing
anything, that's the proper way to get that information, which is
precisely the value from Config-Version. I'm thus closing the bug
report.

Thanks,
Guillem

--- End Message ---

Reply via email to