Silently breaking on upgrade

[The Wanderer-3]

I am not certain that this is the correct list for this question; it is
a question about Debian's policy, but I am not certain that it is about
the type of policy which is covered by the debian-policy manual and thus
the type which is to be discussed here.

I have not been able to find a formal statement of what is and is not
considered on-topic for this mailing list. If this question does not
belong here, please let me know where it should go and I will gladly
take it there.


The question itself, in its starkest form, is simple.

Under what circumstances, if any, is it considered acceptable for a
package which is installed as a dependency by the upgrade of another
package to silently break the system?

--
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mark brown-22]

On Tue, Oct 13, 2009 at 09:37:26AM -0400, The Wanderer wrote:

> The question itself, in its starkest form, is simple.

> Under what circumstances, if any, is it considered acceptable for a
> package which is installed as a dependency by the upgrade of another
> package to silently break the system?

That sounds like something that's so blindingly obviously a bad idea for
any package that you'd hope it doesn't need to be in policy?


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[sean finney]

hi,

On Tue, Oct 13, 2009 at 09:37:26AM -0400, The Wanderer wrote:
> Under what circumstances, if any, is it considered acceptable for a
> package which is installed as a dependency by the upgrade of another
> package to silently break the system?

what defines "silently break the system"?  that's pretty broad for
a specific answer...


        sean

[The Wanderer-3]

On 10/13/2009 09:50 AM, sean finney wrote:

> hi,
>
> On Tue, Oct 13, 2009 at 09:37:26AM -0400, The Wanderer wrote:
>
>> Under what circumstances, if any, is it considered acceptable for a
>> package which is installed as a dependency by the upgrade of
>> another package to silently break the system?
>
> what defines "silently break the system"?  that's pretty broad for a
> specific answer...

"Silently", in this instance, means that A: the change happens without
any kind of notification, and B: that the change won't necessarily be
noticed immediately.

"Break" in this instance means that the parts of the system related to
the package worked fine before the installation, and will fail to work
properly afterwards. In the specific case I'm considering, it also means
that in some configurations the entire system may become unusable,
because the package in question is a window manager.

I'm hesitant to go into more specifics than that - even though I know
they're likely to be necessary - because I know that I'm not especially
objective on the subject, and I don't want to start ranting or
complaining or demanding or for that matter simply whining. I do have
quite a bit more detail to go into if need be, but if the question can
be addressed before that detail is provided, I'd prefer to do things
that way.


(Also, unrelated: the Debian mailing list etiquette page says not to CC
someone on a post to the list unless specifically requested. However,
hitting Reply on a list message populates the To field only with the
previous poster's own address, and hitting Reply-To includes both
addresses, so that not sending the CC requires manually editing the
addressee list. Isn't this inconsistent?)

--
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[The Wanderer-3]

On 10/13/2009 11:19 AM, The Wanderer wrote:

> (Also, unrelated: the Debian mailing list etiquette page says not to
> CC someone on a post to the list unless specifically requested.
> However, hitting Reply on a list message populates the To field only
> with the previous poster's own address, and hitting Reply-To includes
> both addresses, so that not sending the CC requires manually editing
> the addressee list. Isn't this inconsistent?)

Oops - that should be "Reply To All", not "Reply-To".

--
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[The Wanderer-3]

On 10/13/2009 09:47 AM, Mark Brown wrote:

> On Tue, Oct 13, 2009 at 09:37:26AM -0400, The Wanderer wrote:
>
>> The question itself, in its starkest form, is simple.
>
>> Under what circumstances, if any, is it considered acceptable for a
>> package which is installed as a dependency by the upgrade of
>> another package to silently break the system?
>
> That sounds like something that's so blindingly obviously a bad idea
> for any package that you'd hope it doesn't need to be in policy?

That's what I'd have thought, but I've run across a package which does
seem to do this, and the maintainer seems to consider it an acceptable
situation. Before trying to argue too much about that, I wanted to
confirm that it was in fact 'officially' considered unacceptable. (In
fact I'd prefer to exhaust reasonable means of resolving the problem
first, if at all possible - I don't like getting into arguments.)

--
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Tue, 13 Oct 2009, The Wanderer wrote:
> That's what I'd have thought, but I've run across a package which does
> seem to do this, and the maintainer seems to consider it an acceptable
> situation. Before trying to argue too much about that, I wanted to
> confirm that it was in fact 'officially' considered unacceptable.

Breakage is a bug. In some cases fixing the breakage is not possible,
or would introduce other problems (or the breakage isn't even breakage
in the first place) so without knowing details, there's nothing else
we can say.


Don Armstrong

--
There are two types of people in this world, good and bad. The good
sleep better, but the bad seem to enjoy the waking hours much more.  
 -- Woody Allen

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mark brown-22]

On Tue, Oct 13, 2009 at 11:23:26AM -0400, The Wanderer wrote:

> That's what I'd have thought, but I've run across a package which does
> seem to do this, and the maintainer seems to consider it an acceptable
> situation. Before trying to argue too much about that, I wanted to
> confirm that it was in fact 'officially' considered unacceptable. (In
> fact I'd prefer to exhaust reasonable means of resolving the problem
> first, if at all possible - I don't like getting into arguments.)

Perhaps if you were to point at the specific example it might be clearer
what's going on here?


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[The Wanderer-3]

On 10/13/2009 11:38 AM, Don Armstrong wrote:

> On Tue, 13 Oct 2009, The Wanderer wrote:
>
>> That's what I'd have thought, but I've run across a package which
>> does seem to do this, and the maintainer seems to consider it an
>> acceptable situation. Before trying to argue too much about that, I
>> wanted to confirm that it was in fact 'officially' considered
>> unacceptable.
>
> Breakage is a bug. In some cases fixing the breakage is not possible,
> or would introduce other problems (or the breakage isn't even
> breakage in the first place) so without knowing details, there's
> nothing else we can say.

Very well. Here's the situation; I'll try to present it as neutrally as
I can, but I'm not sure how well I'll succeed. As I said, I know that
I'm not as objective about this as I'd like to be.


The e16keyedit package used to depend on (or, rather, recommend) the
enlightenment package. It now recommends on the e16 package. The
enlightenment package has been removed from Debian, with the
justification that it has been replaced by the e16 package.

The enlightenment package provides /usr/bin/enlightenment. The e16
package does not provide either a binary or a symlink at this location.

As a result, if someone who invokes enlightenment from ~/.xinitrc (a not
uncommon place to invoke the window manager AFAIK) instead of from e.g.
/etc/X11/xinit/xinitrc installs e16 - which they will be prompted to do
if they attempt to upgrade e16keyedit - they will wind up in a situation
in which X will fail to launch because the window manager command is not
found; this is part of what I consider breaking the system. However,
they will not notice this until the next time they attempt to launch X -
which, for many people, may be days or weeks or even months later; this
is part of why I consider the breakage to be silent.

(I have not tested, but I would expect that if this happens to someone
who also uses a graphical login prompt, they might find themselves
unable to even get a shell to try to fix the problem. In this case, the
entire system could become unusable.)


This by itself would not be a fatal problem, if the user could simply
change the window manager invocation from 'exec enlightenment' to 'exec
e16' and have their system back. It is, however, not that simple.

The enlightenment package stores its user-specific configuration in
~/.enlightenment/, and the e16 package stores its user-specific
configuration - in an apparently incompatible format - in ~/.e16/.
Simply changing the window-manager invocation will result in losing all
configuration which may have been done; simply copying one directory to
the other does not seem to be a viable way to retain it, because of the
incompatibilities. Depending on how much configuration had been done,
this can be anything from completely negligible to a major, intolerable
problem.


It is, of course, not practical - or even necessarily desirable - to
automatically modify configuration in users' home directories during a
package upgrade. I do not expect this to be done.

I do, however, think it is unreasonable for this type of potentially -
and, in my experience, actually - system-breaking change to happen
without the user being alerted, at install time (perhaps via
apt-listchanges), to the fact that it is going to happen and that manual
changes will be required in order to fix it. Preferably, such an alert
would include a pointer to directions on how to make those manual
changes, or possibly even to a way to automatically make those changes
on a per-user basis.


When I filed a bug report about this behavior, it was closed fairly
promptly on the grounds that there is not supposed to be a migration
path from enlightenment to e16. While I'm not happy with that fact
itself, it's fair enough in one respect. What isn't, and indeed is IMO
unacceptable on its face, is for the lack of a migration path - combined
with the fact that e16 is stated to be replacing enlightenment - to
silently lead to an unusable, or at least effectively crippled, system.


The package maintainer for the e16 and enlightenment packages has stated
in mail to me that he has no plans to change e16 to accommodate an
upgrade from enlightenment. Given the existence of this breakage, he
therefore seems to be taking the position that this breakage is acceptable.

I would normally consider almost any breakage, much less silent
breakage, to be unacceptable. If others do consider it acceptable, then
unless all breakage is considered acceptable (which is plainly not the
case), there must be some criteria for when it is acceptable and when is
not - which was my original question.

--
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

The Wanderer <wanderer@...> writes:

> The e16keyedit package used to depend on (or, rather, recommend) the
> enlightenment package. It now recommends on the e16 package. The
> enlightenment package has been removed from Debian, with the
> justification that it has been replaced by the e16 package.

> The enlightenment package provides /usr/bin/enlightenment. The e16
> package does not provide either a binary or a symlink at this location.

> As a result, if someone who invokes enlightenment from ~/.xinitrc (a not
> uncommon place to invoke the window manager AFAIK) instead of from e.g.
> /etc/X11/xinit/xinitrc installs e16 - which they will be prompted to do
> if they attempt to upgrade e16keyedit - they will wind up in a situation
> in which X will fail to launch because the window manager command is not
> found; this is part of what I consider breaking the system. However,
> they will not notice this until the next time they attempt to launch X -
> which, for many people, may be days or weeks or even months later; this
> is part of why I consider the breakage to be silent.

Oh, and e16 conflicts with enlightenment, so it would remove the old
package and the old binary.

Hm, it's unfortunate that e16 conflicts with enlightenment so that people
can't have both installed to do the transition.  Does anyone know why
there's a conflict?  It sounds like they don't have the same binary name;
did they conflict on other files?

> When I filed a bug report about this behavior, it was closed fairly
> promptly on the grounds that there is not supposed to be a migration
> path from enlightenment to e16.

Well, that's fine, but in that case the Conflicts should really be avoided
if possible so that the user isn't forced to remove the old package.

> The package maintainer for the e16 and enlightenment packages has stated
> in mail to me that he has no plans to change e16 to accommodate an
> upgrade from enlightenment.

I agree with that stance if upstream doesn't provide any upgrade path, but
I think allowing them to be co-installed would be nice.  However, I don't
know what might be in the way of doing that.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

The Wanderer <wanderer@...> writes:

> (Also, unrelated: the Debian mailing list etiquette page says not to
> CC someone on a post to the list unless specifically requested.

Right, thanks for taking notice of that.

> However, hitting Reply on a list message populates the To field only
> with the previous poster's own address

Yes, because you're using the “reply to author” operation of your MUA.

> and hitting Reply-To [all] includes both addresses

Yes, because you're using the “reply to all” operation of your MUA.

> so that not sending the CC requires manually editing the addressee
> list.

You should use the “reply to list” operation of your MUA (or, if your
MUA doesn't have that, pressure the vendor to fix it or switch to an MUA
that does implement it).

> Isn't this inconsistent?)

No, it's your MUA providing different operations for the different ways
you might want to reply to a message. The message itself contains all
the information your MUA needs to provide those options to you.

--
 \       “People come up to me and say, ‘Emo, do people really come up |
  `\                                            to you?’” —Emo Philips |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[The Wanderer-3]

On 10/13/2009 02:18 PM, Russ Allbery wrote:

> The Wanderer <wanderer@...> writes:
>
>> The e16keyedit package used to depend on (or, rather, recommend)
>> the enlightenment package. It now recommends on the e16 package.
>> The enlightenment package has been removed from Debian, with the
>> justification that it has been replaced by the e16 package.
>
>> The enlightenment package provides /usr/bin/enlightenment. The e16
>> package does not provide either a binary or a symlink at this
>> location.
>
>> As a result, if someone who invokes enlightenment from ~/.xinitrc
>> (a not uncommon place to invoke the window manager AFAIK) instead
>> of from e.g. /etc/X11/xinit/xinitrc installs e16 - which they will
>> be prompted to do if they attempt to upgrade e16keyedit - they will
>> wind up in a situation in which X will fail to launch because the
>> window manager command is not found; this is part of what I
>> consider breaking the system. However, they will not notice this
>> until the next time they attempt to launch X - which, for many
>> people, may be days or weeks or even months later; this is part of
>> why I consider the breakage to be silent.
>
> Oh, and e16 conflicts with enlightenment, so it would remove the old
> package and the old binary.

Yes, you're right. I thought that that behavior was happening because
e16 "Replaces: enlightenment", since it's presented as a replacement in
the bug reports requesting that the enlightenment package be removed,
but on closer examination no such line is present in the e16 package.

> Hm, it's unfortunate that e16 conflicts with enlightenment so that
> people can't have both installed to do the transition.  Does anyone
> know why there's a conflict?  It sounds like they don't have the same
> binary name; did they conflict on other files?

According to a diff of the result of "dpkg -c | sed 's/^[^\.]*\././g'"
on the latest .deb files I have for each, the only paths they seem to
have in common are directories like /usr/ and /usr/share/. So, probably
no other-files conflict.

As to why it's listed as being a conflict, my understanding is that the
upstream e16 used to be called enlightenment - that upstream, in fact,
considers them to be in some sense different versions of the same
package. (This is part of why it seems to me that there *should* - in
the sense which is similar to "must" - be a migration path. That's a
separate argument, however.) I seem to recall that the maintainer said
that he had been being pressed by the e16 people to have Debian go along
with that name change, but I don't think I know any of the details.

>> When I filed a bug report about this behavior, it was closed fairly
>> promptly on the grounds that there is not supposed to be a
>> migration path from enlightenment to e16.
>
> Well, that's fine, but in that case the Conflicts should really be
> avoided if possible so that the user isn't forced to remove the old
> package.
>
>> The package maintainer for the e16 and enlightenment packages has
>> stated in mail to me that he has no plans to change e16 to
>> accommodate an upgrade from enlightenment.
>
> I agree with that stance if upstream doesn't provide any upgrade
> path, but I think allowing them to be co-installed would be nice.
> However, I don't know what might be in the way of doing that.

I don't know whether it would qualify as a upgrade path, since it isn't
properly automatic, but AFAIK all that would be required to migrate from
one to the other is to convert ~/.enlightenment (et al.) to the format
of ~/.e16 - which could apparently be done with a few fairly simple
scripts - and either make /usr/bin/enlightenment a symlink, or change
the window-manager invocation in ~/.xinitrc from enlightenment to e16.

However, strongly though I feel that there should be a proper migration
path, the minimum I'm really expecting in this case is to avoid the
potential for having the system break under someone's feet without their
being alerted to the fact - preferably before it happens. Doing so
without abandoning the user to "old Enlightenment, with no further
updates" would be much preferable, but if there's no possibility of
that...

--
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

The Wanderer <wanderer@...> writes:

> As to why it's listed as being a conflict, my understanding is that the
> upstream e16 used to be called enlightenment - that upstream, in fact,
> considers them to be in some sense different versions of the same
> package. (This is part of why it seems to me that there *should* - in
> the sense which is similar to "must" - be a migration path. That's a
> separate argument, however.) I seem to recall that the maintainer said
> that he had been being pressed by the e16 people to have Debian go along
> with that name change, but I don't think I know any of the details.

This isn't really a good reason for a conflict when there's no upgrade
path from the old package to the new package, for precisely the reason
that you ran into.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...