Subject: Re: coreutils: critial files in /bin deleted during dist-upgrade from stable to testing

From: Jonathan Nieder <[email-masked]>
Date: Sat, 26 Mar 2011 05:04:16 -0500

# unconfuse myself
unmerge 255969
quit

Hi,

David Kalnischkies wrote:
>> Brian Frank wrote:

>>> -When running dist-upgrade from stable to testing, many of the important
>>> files in /bin disappeared. I found that they were provided by the
>>> "fileutils" package in stable, but by the "coreutils" package in testing.
>>> Without some of these files (mv, ln, mkdir, etc), the dist-upgrade came to
>>> a screeching halt.
>
> I can't imagine a circumstance in which this could have happened.

Sounds good to me. :)  I was just reading through the merged bugs;
this one is from June, 2004 and I doubt the problem still exists
(though I suppose masochistic types can always try to recreate the
upgrade from that date).

> The only very very very wild wild guess is something like the fixed #590438
> in which the essential is removed too early

Yes, it's possible.  Anyway, this bug seems past the point of
debuggability, so I'll close it with my next message.

> If any version in any repository is essential then the package is essential.
> So for APT a package can only 'loose' its essential flag if you remove
> the archive in which the package is marked as essential.

Sounds sensible to me.  The only edge case I can think of is if
someone has a repository listed in sources.list and does not have any
packages installed from it.

---

From: Jonathan Nieder <[email-masked]>
Date: Sun, 16 Oct 2011 21:15:15 -0500

tags 216768 = wontfix
quit

Hi David,

David Kalnischkies wrote:

> This approach makes mistakes for granted and isn't optimal in all cases,
> but given that the consequences can be a lot worser if a essential is
> missing than they can be if a transition package is still installed
> (which is more or less the only time people really see/complain about it)
> i don't really see why it should be changed. And so far nobody else
> could provide a good reason… so i don't change what isn't broken. ;)

Thanks for this nice explanation!  I'm marking the bug as "wontfix" so
the explanation can be better known (and to get the bug off my radar).

Maybe some day someone will put just the right words in some manpage to
even allow the bug to be closed. ;-)

---

From: Vincent Lefevre <[email-masked]>
Date: Mon, 17 Oct 2011 09:44:54 +0200

> even allow the bug to be closed. ;-)

I disagree about the wontfix. You need to look at all the other merged
bugs, in particular bug 282278, which is about a confusing warning
message.

-- 
Vincent Lefèvre <[email-masked]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

---

From: Vincent Lefevre <[email-masked]>
Date: Mon, 17 Oct 2011 13:34:37 +0200

unmerge 282278
retitle 282278 apt mixes essential flag from all sources for "apt-get remove"
tags 282278 - wontfix
severity 282278 normal
thanks

Explanations below. In short: unmerge because the context is different
for "apt-get dist-upgrade" and "apt-get remove", retitle to make this
clear, removed wontfix that was added for "apt-get dist-upgrade",
severity downgraded to normal (would also be minor) because this is
just a confusing (incorrect) warning message.

On 2011-10-17 03:01:54 -0500, Jonathan Nieder wrote:
> Vincent Lefevre wrote:
> For reference:
>  Description: The GNU shell programming utilities (transitional package)
>   Empty package to facilitate upgrades, can be safely removed.
> 
>  # apt-get remove --purge shellutils textutils
> [...]
>  WARNING: The following essential packages will be removed
>  This should NOT be done unless you know exactly what you are doing!
> 
> That was a bug in the package descriptions of the transitional
> packages.  A transitional package that is used to satisfy versioned
> dependencies should say something like "This is a dummy package to
> satisfy dependencies on foo using its old name.  It can safely be
> removed if no other package depends on it."

This is another problem, specific to dummy packages, and not related
to essential packages (it is worse to remove essential packages, but
this is not what triggered the warning here).

Note: if an essential package will be removed due to a dependency,
the warning should be triggered because of the attempt to remove
this essential package. But this is *not* the case of this warning
here.

> The transitional package shellutils was in a similar situation:
> 
>  Empty package to facilitate upgrades. The essential functionality
>  previously provided by shellutils is part of the coreutils package
>  now; this package exists to satisfy dependencies (including the
>  implicit dependency by all packages in etch) on the old name and
>  can be safely removed if no package depends on it.
> 
> However, it's possible the warning when removing a package that is
> considered essential for this reason and that lacks the Essential: yes
> flag should be reworded to make this clearer.  If you have ideas for
> that, please unmerge bug 282278 so it can happen.

shellutils wasn't lacking "Essential: yes". This shellutils package
had

  Pre-Depends: coreutils

So, once shellutils had moved to a dummy package, the coreutils
version with "Essential: yes" was necessarily installed. And
there was no risk to remove shellutils concerning essential
packages (I mean, removing shellutils would never have removed
coreutils automatically: that was shellutils that (pre-)depended
on coreutils, not the opposite).

The warning was triggered here just because (according to what was
said) I had something like:

deb ... stable main contrib non-free

in my /etc/apt/sources.list file, and that the shellutils version
from Debian/stable had "Essential: yes". But what is wrong is that
the version that was currently installed (and was requested to be
removed) was from testing or unstable, and it was not essential.