Re: Discriminating between install after purge and install from state rc?

[Adeodato Simó <asp16@alu.ua.es>]

* 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.