* Frank Küster [Tue, 05 Apr 2005 16:36:55 +0200]: OK, after having a look at that section in Policy that every maintainer loves (which is, of course, §6 Package maintainer scripts and installation procedure), I think you may find the following bits useful. I can imagine that important parts of them won't be news for you; please excuse those, and feel free to cluebat me if I didn't get your question right.
> Therefore there should be at least one quite straightforward way to > achieve this. But I can only think of doing dpkg queries in preinst and > storing this in /var/tmp - no, there must be something obvious I'm > missing. I don't know what do you mean with "dpkg queries", but knowing if you're coming from 'rc' state is easily done from preinst: preinst - (a) if $1 == upgrade ==> package is already installed (b) if $1 == install ==> package is not installed (b.1) if $2 == "" --> coming from purged (b.2) if $2 != "" --> coming from 'rc', being $2 the latest version installed You can't know the above from the postinst, though, which is why you'd have to use /var/tmp to get such information at configure time (unless I overlooked something). __However__, I miserably fail to see why you want such information at configure time: > How can I find out in postinst whether the package previously had been > in state "rc", or was purged or never installed? It seems every > maintainer script that handles a configuration file must check that - > otherwise it would violate policy's "must preserve local changes" If you are generating the configuration file, it's not different (I can't see how it'd be) whether you came from 'rc' or from already installed, the only that should matter is whether you come from purged or not. If you come from purged, you can blindly create the file; if not (which means, you come either from 'rc' or from already-installed), you must not touch/create the file unless it already exists (unless you're introducing it in this version, which is the obvious case, or you're upgrading from a version which didn't create it, which is not so obvious and perhaps unlikely). So I can be wrong, but for me, the classification needed in postinst would be only two-way, not three way. Please let me know if three-way classification can be relevant under some circumstances. Just to mention it for completeness sake, the arguments to postinst give such information like this: postinst with $1 == configure (a) if $2 == "" ==> coming from purged: can create file blindly (b) if $2 != "" ==> coming from installed (at version $2) or 'rc' (with $2 being the last version): can update file if file exists OR file is new in this version OR $2 < the version in which the file was first introduced. And oh well, I think that's all for now. HTH and all that stuff. ;-) Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 A conclusion is simply the place where someone got tired of thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]