[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Mon, 16 May 2011 22:25:45 -0300, Henrique de Moraes Holschuh
<hmh@debian.org> wrote:
> Because the initscript returned status 0 when there were still
> cryptsetup-managed dm-crypt devices active?  If it does that, it is
> broken.
AFAIU just this happens right now.


> Because the package allowed itself to be uninstalled while the
initscript
> was returning an error?  If it does that, it is broken IMO.
I think cryptsetup is special here,... and successful stopping is quite
likely not to work during uninstall (e.g. dm-crypted root-fs).
We shouldn't call this from the maintainer scripts.


> Because the initscript returned status 0 when there were NO
> cryptsetup-managed dm-crypt devices, but some other sort of dm-crypt
> device?  The user should have known better.
Actually I'm not sure on how /etc/init.d/cryptdisks and -early are
intended with respect to this.
Jonas, should they also handle (i.e. close) any unmanaged dm-crypt
devices?
Wouldn't be to bad, if stopping is just tried for any open device e.g. on
shutdown, would it?


> The conffile issue is not going to change, ever.  Our respect for the
> local administrator during package upgrades It is one of the major
things
> that sets Debian apart from the rest.
Honestly I don't see how this gives or takes freedom.
Of course there are always people that wanna change anything, but then...
what's the big difference between e.g. the crpytsetup initscripts and
cryptdisk.funcitons?
Both scripts, both handle cryptdisks, but we give the former special
status as confile and not the later.
I know this discussion doesn't belong here... but init-scripts are IMHO
just code and especially not configuration.
If the script is well written, it can be fully configured via
/etc/defaults/fooo
If this is not enough for an admin he should need to take care himself,
also on updates.
This is as we already handle ALL other scripts which were simply not put
in /etc/init.d.

Taking myself as an example, I've forked my own personal cryptsetup
package due to several concerns... and I also modify some non-/etc/init.d/
scripts there,... if I change them,.. it's my responsibility to take care
of them.


> Note that I am against cryptsetup allowing itself to be removed while
> devices *it manages* are still open in the first place.
The more I think about it... the more I could like the idea,... but ONLY
if it refuses to be removed if *any* dm-crypt device is still open.
We really shouldn't make different grades of devices where one handled
more important than the other.


Cheers,
Chris.


Reply to: