[pkg-cryptsetup-devel] Bug#626641: Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

[Henrique de Moraes Holschuh]

On Sun, 15 May 2011, Jonas Meurer wrote:
> > - But if the package is installed and removed (but not purged) some
> > additional caution should be taken. I'd suggest using e.g. debconf (with a

"should"?  We hardly hand-hold our users that much.  You have removed the
package, all functionality it provides is *GONE*.  It *is* *that* *simple*,
and it is the truth for _ALL_ packages.

In fact, it is a serious bug for any package in the removed-but-not-purged
state to affect the running system in any way other than use up some storage
and dpkg database space.

> While I do understand your motivation, I don't think that a warning as
> removal time is appropriate. If people remove the cryptsetup package,
> they should expect, that the functionality provided by the package goes
> away with the package. After all they *remove* software.

Agreed.  You *could* use postrm to output a single line, no-debconf, to the
terminal, that states "cryptsetup: package removed, all cryptdisk functions
are now unavailable".  But this is _entirely_ unnecessary IMO.

> I can imagine loads of software that whould have to warn the user while
> being removed. This is valid for any kind of crypto applications at
> least.

And any critical services, etc.  No, let's not go down that path.  At most
we do it for bootloaders and the kernel, and AFAIK we're not doing much of
it even for those two very small classes of packages, even.

We usually warn only when it will break your system _right then_, and
probably make things very hard to fix.  Messing with the running kernel,
messing with 'essential' packages...

> Checking for unlocked dm-crypt devices at cryptsetup package removal,
> and warn the user only in case s/he has open dm-crypt devices, might be
> an option.

That one would make sense, actually.

> I see your point. And I don't know the reasons why initscripts are
> treated as config files in the first place (beside them being in /etc).

Because we often have to modify them locally, and it is no rare thing
either.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh