Control: severity -1 wishlist On Sat, 2013-08-10 at 18:07:03 +0200, Michael Stapelberg wrote: > 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.
I'd be curious to know about that workaround. > 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”. If the policy is to enable all packages on installation, why not have them enabled by default? I guess it needs to modify the filesystem somehow? > 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. Another option might be to have two interfaces, one for the packaging system and another one for users so that the different settings do not clash. > 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): On unpack the package will have a Config-Version field on the dpkg database if it has been configured before, otherwise no such field will be present. > 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? It does not know “that” status, only the immediate previous one, when configuring that would be “unpacked” for example, nothing more. The only think it knows, as mentioned above is if has been previously fully configured before, and what version that was. > Let me know if sending a patch will push this forward faster, but I am > not familiar with dpkg’s source at all. Well, I guess Config-Version is established enough that it should not be considered an internal implementation detail, so you should be able to rely on it. In which case there would be no need for any change to dpkg. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
