> Now let's analyze: What does emacsen-common.postinst really do?
> It does several things, but it basically creates the file
> /var/lib/emacsen-common/installed-flavors as an empty file
> if it does not exist. This is a trivial task which could well
> be done by emacs-package-install, it's not such a complex task.
But it also makes the guarantee that if a postinst succeeds, then
emacsen-common (and whatever packages are properly configured using
it) are properly installed and ready to go.
What I'm vaguely concerned about is setting emacsen-common up in any
way that can make it look like everything's OK, when in fact say gnus
(for example), is now misconfigured (or partially configured) in some
way that can lose mail. I'm not *sure* this is critical, but I'm not
sure it's not either, and hence my hesitation. I'm also wondering
about how this problem might be amplified by broken emacsen-packages
that other emacsen packages depend on (i.e. if gnus depends on
mail-foo-el, and mail-foo-el doesn't get set up right).
Causing the install to fail at least guarantees that it will be
obvious that something's wrong, and may prevent compounding the
problem by proceeding anyway.
I suppose one possibility might be to change the error to say
something like "It looks like this package is using the emacs
infrastructure improperly, please report this as a bug, and, as a
temporary fix, you should probably be able to just remove this package
and then resume your install/upgrade." Would that address any of your
concerns, or would it still be too severe?
> For this reason I think the lack of fault-tolerance is disproportionate.
> It's just a matter of creating a single file.
To me it's not "creating the single file" that's my main concern, it's
the semantic implications of exiting without an error code when
emacsen-common knows something has gone wrong.
Don't get me wrong, I'm not convinced either way yet, but I need to
think it over a bit more before I could comfortably decide to change
the behavior. I'll think about it a bit, and perhaps ask on
debian-emacsen.
Santiago Vila <email address hidden> writes:
> Now let's analyze: What does emacsen- common. postinst really do? emacsen- common/ installed- flavors as an empty file install, it's not such a complex task.
> It does several things, but it basically creates the file
> /var/lib/
> if it does not exist. This is a trivial task which could well
> be done by emacs-package-
But it also makes the guarantee that if a postinst succeeds, then
emacsen-common (and whatever packages are properly configured using
it) are properly installed and ready to go.
What I'm vaguely concerned about is setting emacsen-common up in any
way that can make it look like everything's OK, when in fact say gnus
(for example), is now misconfigured (or partially configured) in some
way that can lose mail. I'm not *sure* this is critical, but I'm not
sure it's not either, and hence my hesitation. I'm also wondering
about how this problem might be amplified by broken emacsen-packages
that other emacsen packages depend on (i.e. if gnus depends on
mail-foo-el, and mail-foo-el doesn't get set up right).
Causing the install to fail at least guarantees that it will be
obvious that something's wrong, and may prevent compounding the
problem by proceeding anyway.
I suppose one possibility might be to change the error to say
something like "It looks like this package is using the emacs
infrastructure improperly, please report this as a bug, and, as a
temporary fix, you should probably be able to just remove this package
and then resume your install/upgrade." Would that address any of your
concerns, or would it still be too severe?
> For this reason I think the lack of fault-tolerance is disproportionate.
> It's just a matter of creating a single file.
To me it's not "creating the single file" that's my main concern, it's
the semantic implications of exiting without an error code when
emacsen-common knows something has gone wrong.
Don't get me wrong, I'm not convinced either way yet, but I need to
think it over a bit more before I could comfortably decide to change
the behavior. I'll think about it a bit, and perhaps ask on
debian-emacsen.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4