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

[Jonathan D Reed]

On Jun 19, 2014, at 11:33 AM, Kernc <kerncece at gmail.com> wrote:
> 
> Firstly, kudos on this neat and handy piece of middleware!

Thanks — we’re always glad to hear of others using it.

> I want to divert /etc/skel/.bashrc. I'm trying to _hide_ it instead of
> displacing to avoid creation of superfluous and confusing files with a
> symlink in user's home.

Can you include a link to your code, as well as some details about your build distribution and target distribution(s)?  In a simple test, I am able to hide /etc/skel/.bashrc using config-package-dev 5.12 (though 5.0 should be fine).

> Could the condition be loosened a little? Currently, the first
> condition, [ ! -L ... ], is excessive anyway since [ ! -e ... ] covers
> it.

Not necessarily.  -e dereferences symlinks, and -L does not.  If the symlink existed but was broken, “[ ! -e $file ]” would be true, but "[ ! -L $file ]” would not.  If there’s a broken symlink, something clearly went wrong and/or the user deliberately broke it (see the “OMINOUS WARNING” code the *_symlink functions), so rather than remove the diversion and scribble over the destination (per —rename), we abort and let the user recover.

> I managed to get the package install/upgrade/purge as I expect it by
> manually dpkg-diverting to /usr/share in preinst, with link pointing
> to my version in /usr/share, and removing the diversion in *postrm*.
> Why is the hide diversion in c-p-d lifted in prerm?

Seeing your code would help here, since as noted above, I’m able to do this in a simple example.

> This slightly contradicts⁴
> 
>> Do not give the replacement cron job the same name as the original one ...
>> If you do, it will not be possible to install your package in the same apt invocation ....
> 
> [4]: https://debathena.mit.edu/config-packages/#The_hide_operation

I don’t think this warning applies to the situation you described.  This warning is advising against creating a package that hides a file, and then replaces it with another file of the same name and path.  Despite the local diversion of one file, I believe APT will still think the two packages ship the same file (because in fact, they do) and refuse to install them in the same transaction.

-Jon