"dpkg -s shellutils" says:

Package: shellutils
Status: install ok installed
Priority: extra
Section: oldlibs
Installed-Size: 16
Maintainer: Michael Stone <mstone@debian.org>
Architecture: all
Source: coreutils
Version: 5.2.1-2
Pre-Depends: coreutils
Description: The GNU shell programming utilities (transitional package)
 Empty package to facilitate upgrades, can be safely removed.

(ditto for textutils). So, I assume I can remove them. But
"apt-get remove --purge shellutils textutils" says:

WARNING: The following essential packages will be removed
This should NOT be done unless you know exactly what you are doing!
  shellutils textutils
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 32.8kB disk space will be freed.
You are about to do something potentially harmful
To continue type in the phrase 'Yes, do as I say!'

This is rather contradictory!

merge 216768 282278
thanks

Already reported.

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 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."  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.

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.
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.

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.

Vincent Lefevre wrote:

Yes, I know that.  But how could apt know?

Imagine that we were not just shifting around names, but actually
successfully eliminated some functionality from the essential set.
For example, let's say in wheezy+20, that perl-base is no longer
essential.  Then:

I upgrade perl-base to wheezy+20, but I still have packages from
wheezy+19, whose maintainer scripts (e.g., preinst) use perl without
depending on it.  Then apt _must_ prevent me from casually removing
perl-base.

Ideas for rewording the error message to make its purpose clearer
would be very welcome.

Ah, OK.
were essential in the past but are no longer essential. For instance:

WARNING: The following packages were essential in the past and will
be removed. Though no longer essential, these packages may still be
needed by other (older) packages. Please look at the description of
these packages to see if it is safe to remove them.

Would that be OK?

Also, if apt could detect that some such package is a dummy package
(i.e. with files only under /usr/share/doc?), I suppose that it would
not need to output the warning.

Now, with the example above, what if after wheezy+20, perl-base
becomes a package with fewer features, i.e. where some of the
features that were part of the essential package have been moved
to a different package, say perl-extra (not essential either),
with no dependencies of perl-base on perl-extra? The user would
still get the warning if he attempts to remove perl-base, but
what if he attempts to remove perl-extra?

retitle 282278 apt: please clarify warning about removing packages that are essential in another suite
# warning message
severity 282278 minor
quit

Vincent Lefevre wrote:

Sounds fine to me, with the caveat that it's not safe to assume that
the release in which the package was essential is older.  This
condition could be tripped just as easily by the following sequence of
events:

 1. Package "foo", which exists but is not essential in squeeze,
    becomes essential in wheezy.

 2. Sysadmin downgrades foo to the version in squeeze (which is not
    flagged as Essential: yes).

 3. Sysadmin tries to remove foo.

Now, how to get the message in?  Might be better to ask an APT expert
that.  If I were doing it, the logic would be vaguely like this
(except probably I'd factor out a "spawn" function to decrease the
boilerplate).  Hopefully there's some appropriate APT API to look at
the dpkg status database or the appropriate Packages file for the
version of a package being removed.

Untested and probably broken in many ways.  Maybe it can inspire
something sane.

 cmdline/apt-get.cc |   74 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 74 insertions(+), 0 deletions(-)

diff --git i/cmdline/apt-get.cc w/cmdline/apt-get.cc
index 88e7346..7ca4b1b 100644
--- i/cmdline/apt-get.cc
+++ w/cmdline/apt-get.cc
@@ -505,6 +505,77 @@ bool ShowHold(ostream &out,CacheFile &Cache)
    return ShowList(out,_("The following held packages will be changed:"),List,VersionsList);
 }
 									/*}}}*/
+// StatusEssential - Ask dpkg whether a package is essential		/*{{{*/
+// ---------------------------------------------------------------------
+// Returns true on error, too.
+static bool StatusEssential(const pkgCache::PkgIterator &Pkg)
+{
+  string PkgName = Pkg.FullName(false);
+  int Pipes[2];
+
+  if (pipe(Pipes) != 0) {
+    _error->Errno("pipe",_("Failed to create pipes"));
+    return true;
+  }
+
+  pid_t Child = ExecFork();
+
+  if (Child == 0)
+  {
+    int Fd = open("/dev/null",O_RDWR);
+    if (Fd == -1)
+      _exit(101);
+    dup2(Fd,0);
+    dup2(Pipes[1],1);
+    dup2(Fd,2);
+    close(Fd);
+    close(Pipes[0]);
+    close(Pipes[1]);
+
+    const char *Args[5];
+    Args[0] = "dpkg-query";
+    Args[1] = "-W";
+    Args[2] = "-f=${Essential}";
+    Args[3] = PkgName.c_str();
+    Args[4] = 0;
+    execvp(Args[0],(char **)Args);
+    cerr << _("Failed to exec dpkg-query") << endl;
+    _exit(100);
+  }
+
+  FileFd InFd(Pipes[0]);
+  close(Pipes[1]);
+
+  bool Result;
+  unsigned char Buf[16];
+  unsigned long long Size
+
+  if (InFd.Read(Buf,sizeof(Buf),&Size) == false)
+    return true;
+  if (InFd.Eof() == false)
+  {
+    _error->Error(_("Unexpected output from dpkg-query"));
+    Result = true;
+  }
+  else if (Size == strlen("yes\n") && !memcmp(Buf, "yes\n", strlen("yes\n")))
+  {
+    Result = true;
+  }
+  else if (Size == strlen("no\n") && !memcmp(Buf, "no\n", strlen("no\n")))
+  {
+    Result = false;
+  }
+  else
+  {
+    _error->Error(_("Unexpected output from dpkg-query"));
+    Result = true;
+  }
+  InFd.Close();
+  if (ExecWait(Child,"dpkg-query",false))
+    return true;
+  return Result;
+}
+									/*}}}*/
 // ShowEssential - Show an essential package warning			/*{{{*/
 // ---------------------------------------------------------------------
 /* This prints out a warning message that is not to be ignored. It shows
@@ -541,6 +612,9 @@ bool ShowEssential(ostream &out,CacheFile &Cache)
       if (I->CurrentVer == 0)
 	 continue;

+      if (!StatusEssential(I))
+	List += " (only essential in another suite) ";
+
       // Print out any essential package depenendents that are to be removed
       for (pkgCache::DepIterator D = I.CurrentVer().DependsList(); D.end() == false; ++D)
       {

So many mails and i still don't get it…
(i am subscribed to apt bugs, so no need to cc me on everything btw…)
is on the 'oldstable' suite and has 'stable' in it, too, has a funky mix
of it or has completed (=whatever this means) upgraded to 'stable'.

If we go with the wheezy+20 perl-base essential drop example:

If we are on wheezy+19 yet in which perl-base is essential,
we need a really scary message displayed to discourage users to
shoot themselves in the foot, or are we in some funky mixture of it,
maybe because a dist-upgrade failed because of some packaging bug?
In that case what means 'other suite' here? It is just 'not the currently
installed suite for perl-base'? But this tells us nothing, perl-base is or
isn't upgraded yet, but this doesn't say anything about packages
implicitly depending on it, so the message should be still equally scary
as there are potential still packages thinking of perl-base as essential.
Last, we have "fully" upgraded to wheezy+20, perl-base isn't essential
any more for this release, but does all these obsolete packages know this?
And, why does the user have wheezy+19 archive still in the sources.list if
he doesn't get packages from there anymore?
Right, he either still gets packages from there making it a mixed system on
which perl-base needs to be installed as it is essential for exactly the
packages he gets from wheezy+19 sources OR the user wants to clean up his
system by removing now obsolete packages but doesn't start with the most
obvious cleanup step: Removing old sources…

In all but the last case changing the message is just plain wrong.
Beside, the message says:
"This should NOT be done unless you know exactly what you are doing!"
So there is the problem? Users who don't know what they remove?
Yes that is a problem and this message is specifically designed for those.
Users who know what they do? No, as the message explicitly say that you
can proceed if you know what you do.

APT can't determine automatically if something depends implicitely on
this previous/now/future essential package, so it treats all essentials
equally and off-loads the impossible task of taking implicit dependencies
explicitely into account to the user. That might be a problem for the user
as he has nobody to blame for if the system is broken after he hit enter,
but this isn't solveable by software…

So, can somebody please tell me a situation which can be detected without
doubt in which this message is wrong (= in which way can a confirmation
message be wrong?). Maybe i get an answer to it this time…
into the RecordParser gets you access to the complete stanza as you
can see in apt-cache for various operations like show or search as
it needs to work with information we don't have in the binary cache
for various reasons. The essential flag is in this cache, but as
hinted above and said many times in this (ex-)bugcombilation recorded
as a package-attribute and not as a version-attribute for reasons
given (again) above.


Best regards

David Kalnischkies


P.S.: Vincent, Essentials can't just change their featureset.
If they are split up a metapackage with the old name remains,
so removing perl-extra would remove the old 'perl-base' metapackage
which APT complains about as being essential.
Thats also why a heuristic based on package content fails - perl-base
would be in this scenario such a package, so "easy" to remove, but
his dependencies hold the universe together, so to speak…
(Beside that APT just don't know the contents of a package)

David Kalnischkies wrote:
[...]
currently says "WARNING: The following essential packages will be
removed".  A person can easily get confused by running "dpkg -s
<package>" and finding the "Essential: yes" flag is not there.  Maybe
something like

 WARNING: The following packages which are essential in some suite
 will be removed

would avoid that confusion.

I agree with you that "Essential: yes" is technically something like
an implied Pre-Depends from all packages and that this means the
Essential flag on the installed version of a package is not actually
relevant.  But as the 7 or so bugs this used to be merged with
illustrate, that's not necessarily obvious when people first run into
it. :)  Therefore in an ideal world it would be nice to do

 WARNING: The following essential packages will be removed

  fileutils (essential in sarge)
  textutils (essential in sarge)

 This should NOT be done unless you know exactly what you are doing!

I was thinking that an approximation would be to put "some other
suite" instead of "sarge" to at least get the reader thinking along
the right lines; this wouldn't need to involve changing the cache
format since this message does not need to be shown very often so it
can be slow.

I guess even better would be to keep a list of the sources that caused
a package to be considered essential somewhere.  That is a bit beyond
my depth, unfortunately.

But on what source is the scary message based? sources.list only or
something else based on what is installed? (I'm not sure whether
I understood what was said below about VerFileIterators, etc.)

For instance, the user may remove wheezy+19 from sources.list,
but still have old packages installed, so that the scary message
should still occur.

Removing old sources make sense only if the old packages from these
sources are removed too. Otherwise what about security updates?

One problem is that the current message is

  "WARNING: The following essential packages will be removed"

but if the user looks at the installed package, he can see that
it is *not* essential. The user may think: apt is wrong. And he
may remove the package, based on this information. So, it is
important that the warning message is rigorously correct.

Another problem is that the description of the package says:

  Empty package to facilitate upgrades, can be safely removed.
                                               ^^^^^^

and apt says the opposite. The user should get the information to
resolve this contradiction without ambiguity or misinterpretation.

But what if perl-base is no longer essential in some release, and in
the next release, some parts of perl-base are moved to a new package
perl-extra (without perl-base being a metapackage)?

Is this possible, or does Debian carefully check the whole history of
packages to make sure this will never happen?

Sehr geehrte Damen und Herren,

die Arbeitsagentur stellt Ihnen nachfolgend eine interessante Tätigkeit in einem internationalen Team von zu Hause aus vor, ohne Fahrtkosten, ohne Anfahrt, ohne Stau:

Wir bieten qualitative und attraktive Stellen auch in ländlichen Regionen europaweit und bieten gleichzeitig exzellente Qualität für unsere Kunden.

Zur Erweiterung unseres Teams suchen wir ab sofort:
Kollegen (m/w) für den Support im Home Office in der Abteilung Office und Kommunikation

Ihre Aufgaben wären:

- Unterlagen empfangen, bearbeiten und weiterleiten
- Dokumente einscannen/kopieren
- Mails beantworten
- Tätigkeit im Home Office in freien Zeiteinteilung
- Arbeit mit zur Verfügung gestellten Systemen

Wir erwarten:

- Unproblematischer Umgang mit Email, PC und Internet
- Deutsch fließend, Fremdsprachen wären vorteilhaft
- erfolgsorientiertes Arbeiten im Team
- Zielstrebigkeit und Pünktlichkeit

Wir bieten Ihnen einen Arbeitsplatz als Festangestellter oder als Gewerbetreibender mit einem Stundenlohn von 20 Euro Brutto die Stunde in selbständigen Arbeitsweise und einer modernen Beschäftigungsform, sowie eine abwechslungsreiche Tätigkeit ohne Arbeitsweg mit flexiblen Arbeitszeiten.

Es werden keine Fachkenntnisse vorausgesetzt. Die Einarbeitung findet detailliert durch professionelle Mitarbeiten statt. Die benötigte technische Ausstattung stellen wir Ihnen kostenlos zur Verfügung. Die Beschäftigung kann gerne nebenberuflich ausgeführt werden sowie von Rentnern und Hausfrauen.

Sie sind offen für flexible Arbeitszeitmodelle und die Arbeit im Home-office? Wenn wir Ihr Interesse geweckt haben, senden Sie uns Ihre Bewerbung per E-Mail an: HaroldViala@scotlandmail.com


Ihre persönlichen Unterlagen behandeln wir vertraulich.

In Erwartung Ihrer Antwort Ihre

Klein SC