[config-package-dev] unhiding in prerm doesn't work if/because file with the same name still exists

[Jonathan D Reed]

Hi, 

I finally had a chance to take a look at this; sorry for the delay.  In the package you gave me, you’re hiding a file, and then replacing it with a symlink, and then the unhide operation isn’t done in the prerm, because of the preconditions discussed earlier in the thread.  This is unlikely to change — we have no good way of knowing that it’s “ok” to clobber the file when un-hiding.  As you said, we could check to see if the file we’re about to clobber is provided by the package, but then that gets into subtleties with de-configure vs remove vs purge, and would require us to save some state between the prerm and postrm, which further complicates things because of the rollback support (e.g. abort-foo).  It could also easily end up confusing dpkg and/or debsums.  We have tossed around the idea of doing this client-side with, e.g., config-package-dev-maintscript-helper (c.f. dpkg-mainstcript-helper), but then people would have to install a package in order to use config-package-dev generated packages, and that’s undesirable.

That having been said “hide a file and then replace its contents” is basically the divert operation — out of curiousity, why are you symlinking the file from /usr/share, rather than simply providing etc/test-pkg.conf.divert, and letting config-package-dev take care of the symlinking?   I suppose I can see a use case for that if the file needs to _also_ exist in /usr/share for some other reason, and you want to avoid skew between the files.

Is it possible to share your actual code or detailed use-case with us, rather than an abstract example?  Having a sense of real-world situations in which “displace” is not sufficient, but “hide + overwrite in package” is, would help use determine whether or not to allocate the resources into refactoring the maintscript code, and doing some operations in the prerm and some in the postrm (like the way dpkg-maintscript-helper works for things like rm_conffile).

-Jon

On Jun 19, 2014, at 5:02 PM, Kernc <kerncece at gmail.com> wrote:

> The attachment can serve as an example: the xy-test-pkg-config file
> hides /etc/test-pkg.conf and also symlinks into this location its
> replacement from /usr/share. Don't know about APT, but dpkg seems to
> devour both easily. But at removal of the config package, the
> diversion is not removed (because of the said condition in prerm
> script — thanks for correcting me there).
> 
> How else do you recommend I go about diverting bash's
> /etc/skel/.bashrc and provide my customization?
> 
> Couldn't unhide be done in postrm or, alternatively,
> undisplace_unlink_displace() contain some similar logic to the ominous
> warning, namely checking if the existing symlink or file endpoint is
> the one created by this same package? Seems like debhelper uses this
> kind of magic all over the place. :)
> 
>>> Firstly, kudos on this neat and handy piece of middleware!
>> 
>> Thanks — we’re always glad to hear of others using it.
> 
> AFAICT, it's pretty much the canonical way to do this. ;)
> <test-pkg+config.tar.gz>