Subject: apt-get dist-upgrade: wrong handling of formerly-essential packages
Date: Mon, 20 Oct 2003 21:19:09 +0000
Package: apt
Version: 0.5.4
Severity: normal
When pointing to potato and woody, we get a situation where 2 packages (ldso
and update) lost essential status:
$ apt-cache show ldso | grep-dctrl -sPackage,Version,Essential -P ldso
Package: ldso
Version: 1.9.11-15
Essential:
Package: ldso
Version: 1.9.11-9
Essential: yes
"apt-get dist-upgrade" insists on installing essential packages. But in the
light of the present situation, we have a problem to define what to install.
Apparently APT tags ldso and update as "essential" as a whole... and based
on versions decides to force upon us installation of the more recent
non-essential version.
I don't suggest that the older version be installed, but I'd expect APT to
take into account the essential status of the eligible version, and so not
to consider it to be forcedly installed.
Currently, I just cannot make use of dist-upgrade, unless I accept this old
obsolete stuff on my machines, or unless I stop refering to potato.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux winnipeg 2.4.22+nfs-ngroups+preempt+lowlatency-station #1 mer oct 8 17:38:11 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages apt depends on:
ii libc6 2.2.5-11.5 GNU C Library: Shared libraries an
ii libstdc++2.10-glibc2.2 1:2.95.4-11woody1 The GNU stdc++ library
--
Yann Dirson <[email protected]> http://www.alcove.com/
Technical support manager Responsable de l'assistance technique
Senior Free-Software Consultant Consultant senior en Logiciels Libres
Debian developer ([email protected]) Développeur Debian
Subject: Re: Bug#216768: apt-get dist-upgrade: wrong handling of formerly-essential packages
Date: Mon, 20 Oct 2003 15:53:47 -0400
retitle 216768 Essential status is based on packages, not individual versions
thanks
On Mon, Oct 20, 2003 at 09:19:09PM +0000, Yann Dirson wrote:
> When pointing to potato and woody, we get a situation where 2 packages (ldso
> and update) lost essential status:
>
> $ apt-cache show ldso | grep-dctrl -sPackage,Version,Essential -P ldso
> Package: ldso
> Version: 1.9.11-15
> Essential:
>
> Package: ldso
> Version: 1.9.11-9
> Essential: yes
>
>
> "apt-get dist-upgrade" insists on installing essential packages. But in the
> light of the present situation, we have a problem to define what to install.
> Apparently APT tags ldso and update as "essential" as a whole... and based
> on versions decides to force upon us installation of the more recent
> non-essential version.
>
> I don't suggest that the older version be installed, but I'd expect APT to
> take into account the essential status of the eligible version, and so not
> to consider it to be forcedly installed.
>
> Currently, I just cannot make use of dist-upgrade, unless I accept this old
> obsolete stuff on my machines, or unless I stop refering to potato.
Just take potato out of your sources.list. It is obsolete, and you will be
much happier.
--
- mdz
Changed Bug title to 'update-inetd: assumes that /tmp is on the same filesystem as /etc' from 'Essential status is based on packages, not individual versions'
Request was from Julien BLACHE <[email protected]>
to [email protected].
(Thu, 03 Sep 2009 16:18:18 GMT) (full text, mbox, link).
Changed Bug title to '[apt] apt mixes essential flag from all sources' from 'update-inetd: assumes that /tmp is on the same filesystem as /etc'
Request was from Julien BLACHE <[email protected]>
to [email protected].
(Thu, 03 Sep 2009 18:09:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Ivan Vilata i Balaguer <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 10:30:05 GMT) (full text, mbox, link).
Subject: apt: Confirmed under Lenny with several sources and pinning
Date: Mon, 02 Nov 2009 09:56:48 +0000
Package: apt
Version: 0.7.20.2+lenny1
Followup-For: Bug #216768
My APT setup includes sources from Lenny (stable) and Squeeze (testing), pinned so that only
certain packages get pulled from testing. I have ``apticron`` installed and since I made the
mixed setup with pinning, it reports that ``dash`` and ``diffutils`` are pending an upgrade,
when neither of them are installed. It happens that both packages are essential in Squeeze,
but not in Lenny. If I install the Lenny version of ``dash`` and try to remove it with
Aptitude, it insists in the installed package being essential, which is untrue.
Forcing the removal of ``dash`` and ``diffutils`` reverts the system to the same state (i.e.
``apticron`` recommending the upgrade of the uninstalled packages).
-- Package-specific info:
-- apt-config dump --
APT "";
APT::Architecture "i386";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Acquire "";
APT::Acquire::Translation "environment";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^linux-image.*";
APT::NeverAutoRemove:: "^linux-restricted-modules.*";
APT::Default-Release "stable";
Dir "/";
Dir::State "var/lib/apt/";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::userstatus "status.user";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt/";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt/";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::vendorlist "vendors.list";
Dir::Etc::vendorparts "vendors.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::dpkg "/usr/bin/dpkg";
Dir::Log "var/log/apt";
Dir::Log::Terminal "term.log";
DPkg "";
DPkg::Pre-Install-Pkgs "";
DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listchanges --apt || test $? -ne 10";
DPkg::Pre-Install-Pkgs:: "/usr/sbin/dpkg-preconfigure --apt || true";
DPkg::Tools "";
DPkg::Tools::Options "";
DPkg::Tools::Options::/usr/bin/apt-listchanges "";
DPkg::Tools::Options::/usr/bin/apt-listchanges::Version "2";
-- /etc/apt/preferences --
Package: *
Pin: release a=lenny-backports
Pin-Priority: 200
Package: drupal6
Pin: release a=lenny-backports
Pin-Priority: 999
Package: *
Pin: release a=testing
Pin-Priority: 190
Package: prosody
Pin: release a=testing
Pin-Priority: 999
Package: liblua5.1-sec0
Pin: release a=testing
Pin-Priority: 999
-- /etc/apt/sources.list --
deb http://ftp.us.debian.org/debian lenny main
deb-src http://ftp.us.debian.org/debian lenny main
deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main
## <XNX by="ivan" date="2009-10-30">
deb http://www.backports.org/debian lenny-backports main
deb http://ftp.us.debian.org/debian testing main
## </XNX>
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (990, 'stable'), (190, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.18.8-linode16 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages apt depends on:
ii debian-archive-keyring 2009.01.31 GnuPG archive keys of the Debian a
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-1.1 GCC support library
ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
apt recommends no packages.
Versions of packages apt suggests:
pn apt-doc <none> (no description available)
ii aptitude 0.4.11.11-1~lenny1 terminal-based package manager
pn bzip2 <none> (no description available)
pn dpkg-dev <none> (no description available)
ii lzma 4.43-14 Compression method of 7z format in
ii python-apt 0.7.7.1+nmu1 Python interface to libapt-pkg
-- no debconf information
Acknowledgement sent
to Ivan Vilata i Balaguer <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 13:30:07 GMT) (full text, mbox, link).
On the other hand, if I'm using a repository from *testing* and I have
installed some packages from it, it makes some sense that essential packages
from testing must be installed also. However, when I remove all packages from
testing (bar the essential ones), the essential packages from testing which
aren't essential in stable (i.e. ``dash``) are still regarded as essential by
Aptitude.
Maybe the situation became just too sophisticated to handle automatically. :-/
::
Ivan Vilata i Balaguer -- http://ivan.lovesgazpacho.net/
Acknowledgement sent
to Julian Andres Klode <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 13:45:04 GMT) (full text, mbox, link).
Subject: Re: Bug#216768: apt: Confirmed under Lenny with several sources
and pinning
Date: Mon, 02 Nov 2009 14:26:59 +0100
Am Montag, den 02.11.2009, 09:56 +0000 schrieb Ivan Vilata i Balaguer:
> Package: apt
> Version: 0.7.20.2+lenny1
> Followup-For: Bug #216768
>
>
> My APT setup includes sources from Lenny (stable) and Squeeze (testing), pinned so that only
> certain packages get pulled from testing. I have ``apticron`` installed and since I made the
> mixed setup with pinning, it reports that ``dash`` and ``diffutils`` are pending an upgrade,
> when neither of them are installed. It happens that both packages are essential in Squeeze,
> but not in Lenny. If I install the Lenny version of ``dash`` and try to remove it with
> Aptitude, it insists in the installed package being essential, which is untrue.
>
> Forcing the removal of ``dash`` and ``diffutils`` reverts the system to the same state (i.e.
> ``apticron`` recommending the upgrade of the uninstalled packages).
The problem is that the essential state is package specific and not
version specific. This means that as long as there is one essential
version of a package, all versions are considered essential.
But anyway, dash and diffutils are essential in Squeeze, so you must
have them installed if you want to install software from squeeze as such
software may depend on them implicitly.
Maybe it helps to pin those packages with priority -1. If not, it would
be an idea to make this possible so people could manually overwrite
essential packages.
You could also try to use another package manager such as cupt or smart,
and see if they do what you want.
>
> -- Package-specific info:
>
> -- apt-config dump --
>
> APT "";
> APT::Architecture "i386";
> APT::Build-Essential "";
> APT::Build-Essential:: "build-essential";
> APT::Install-Recommends "1";
> APT::Install-Suggests "0";
> APT::Acquire "";
> APT::Acquire::Translation "environment";
> APT::NeverAutoRemove "";
> APT::NeverAutoRemove:: "^linux-image.*";
> APT::NeverAutoRemove:: "^linux-restricted-modules.*";
> APT::Default-Release "stable";
> Dir "/";
> Dir::State "var/lib/apt/";
> Dir::State::lists "lists/";
> Dir::State::cdroms "cdroms.list";
> Dir::State::userstatus "status.user";
> Dir::State::status "/var/lib/dpkg/status";
> Dir::Cache "var/cache/apt/";
> Dir::Cache::archives "archives/";
> Dir::Cache::srcpkgcache "srcpkgcache.bin";
> Dir::Cache::pkgcache "pkgcache.bin";
> Dir::Etc "etc/apt/";
> Dir::Etc::sourcelist "sources.list";
> Dir::Etc::sourceparts "sources.list.d";
> Dir::Etc::vendorlist "vendors.list";
> Dir::Etc::vendorparts "vendors.list.d";
> Dir::Etc::main "apt.conf";
> Dir::Etc::parts "apt.conf.d";
> Dir::Etc::preferences "preferences";
> Dir::Bin "";
> Dir::Bin::methods "/usr/lib/apt/methods";
> Dir::Bin::dpkg "/usr/bin/dpkg";
> Dir::Log "var/log/apt";
> Dir::Log::Terminal "term.log";
> DPkg "";
> DPkg::Pre-Install-Pkgs "";
> DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listchanges --apt || test $? -ne 10";
> DPkg::Pre-Install-Pkgs:: "/usr/sbin/dpkg-preconfigure --apt || true";
> DPkg::Tools "";
> DPkg::Tools::Options "";
> DPkg::Tools::Options::/usr/bin/apt-listchanges "";
> DPkg::Tools::Options::/usr/bin/apt-listchanges::Version "2";
>
> -- /etc/apt/preferences --
>
> Package: *
> Pin: release a=lenny-backports
> Pin-Priority: 200
>
> Package: drupal6
> Pin: release a=lenny-backports
> Pin-Priority: 999
>
> Package: *
> Pin: release a=testing
> Pin-Priority: 190
>
> Package: prosody
> Pin: release a=testing
> Pin-Priority: 999
>
> Package: liblua5.1-sec0
> Pin: release a=testing
> Pin-Priority: 999
>
>
> -- /etc/apt/sources.list --
>
> deb http://ftp.us.debian.org/debian lenny main
> deb-src http://ftp.us.debian.org/debian lenny main
>
> deb http://security.debian.org/ lenny/updates main
> deb-src http://security.debian.org/ lenny/updates main
>
> ## <XNX by="ivan" date="2009-10-30">
> deb http://www.backports.org/debian lenny-backports main
> deb http://ftp.us.debian.org/debian testing main
> ## </XNX>
>
> -- System Information:
> Debian Release: 5.0.3
> APT prefers stable
> APT policy: (990, 'stable'), (190, 'testing')
> Architecture: i386 (i686)
>
> Kernel: Linux 2.6.18.8-linode16 (SMP w/4 CPU cores)
> Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages apt depends on:
> ii debian-archive-keyring 2009.01.31 GnuPG archive keys of the Debian a
> ii libc6 2.7-18 GNU C Library: Shared libraries
> ii libgcc1 1:4.3.2-1.1 GCC support library
> ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
>
> apt recommends no packages.
>
> Versions of packages apt suggests:
> pn apt-doc <none> (no description available)
> ii aptitude 0.4.11.11-1~lenny1 terminal-based package manager
> pn bzip2 <none> (no description available)
> pn dpkg-dev <none> (no description available)
> ii lzma 4.43-14 Compression method of 7z format in
> ii python-apt 0.7.7.1+nmu1 Python interface to libapt-pkg
>
> -- no debconf information
>
>
>
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 16:00:18 GMT) (full text, mbox, link).
Subject: Re: Bug#216768: apt: Confirmed under Lenny with several sources and
pinning
Date: Mon, 2 Nov 2009 16:40:00 +0100
Hi all,
On Tue, 1 Sep 2009, Santiago Vila wrote:
> Thanks, Raphael. This is clearly a problem in apt.
Funny, i think it is a feature and i will try to describe why now. :)
(I want to do it earlier, but i somehow managed to forget it...)
2009/11/2 Ivan Vilata i Balaguer <[email protected]>:
> I have ``apticron`` installed and since I made the
> mixed setup with pinning, it reports that ``dash`` and ``diffutils``
> are pending an upgrade, when neither of them are installed.
> It happens that both packages are essential in Squeeze,
> but not in Lenny.
A user who mixed sources very likely mixes also packages.
As a package doesn't need to depend on essential packages,
apt tries to install in a dist(ribution)-upgrade ALL essential
packages it can find in all sources to protect the user from
dependency hell and as a bonus protect the user from doing something
stupid: Removing a package which is/was/will be essential as it is
maybe required by package on this system (who know how far your
mixing goes, so better save than sorry as Ivan Vilata i Balaguer also
said indirectly in his second message).
On Tue, 1 Sep 2009, Vincent Lefevre wrote:
> I thought that the problem was more serious that it was: inconsistent
> database (since this is what it really appears to be). If the warning
> message were more detailed, one would not need to guess anything.
The message says:
"This should NOT be done unless you know exactly what you are doing!"
So it is already open to the fact that it is maybe wrong to consider
the package essential and that it is really safe to remove it,
but APT thinks it is a lot better to require the user to use special forces
(long confirm message, holds on uninstalled packages) in some cases
instead of let the user destroy his system in many more cases.
I don't see why a user could think of a "inconsistent database" after
read this message, maybe APT could say that this package
was/is/will _maybe_ an essential, but i guess this would be even more
confusing to a user. Suggestions for a better wording?
(I can't think of a better one)
The "real" bug here showed by diff (and a few other before)
is therefore something like this:
New essential package A replaces old essential package B.
(Package B is now a transitional package to A.)
The user (with mixed sources) tries to deinstall package B and
apt refuses that as it thinks B is essential - it doesn't take into
account that A provides the same functionality as B.
Could we agree on that it is a (very) minor bug?
(btw: It is questionable if A really provides the absolutely exact
functionality as B and is therefore really a full replacement but
this is nothing i want to argue about now)
Best regards / Mit freundlichen Grüßen,
David "DonKult" Kalnischkies
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 16:24:10 GMT) (full text, mbox, link).
Subject: Re: Bug#216768: apt: Confirmed under Lenny with several sources and
pinning
Date: Mon, 2 Nov 2009 17:13:23 +0100
On 2009-11-02 16:40:00 +0100, David Kalnischkies wrote:
> The message says:
> "This should NOT be done unless you know exactly what you are doing!"
Well, this was "The following essential packages will be removed."
I found confusing.
> So it is already open to the fact that it is maybe wrong to consider
> the package essential and that it is really safe to remove it,
> but APT thinks it is a lot better to require the user to use special forces
> (long confirm message, holds on uninstalled packages) in some cases
> instead of let the user destroy his system in many more cases.
> I don't see why a user could think of a "inconsistent database" after
> read this message, maybe APT could say that this package
> was/is/will _maybe_ an essential, but i guess this would be even more
> confusing to a user. Suggestions for a better wording?
> (I can't think of a better one)
Perhaps it should be said that the essential state is package
specific and not version specific, because packages may depend
on them implicitly. Otherwise users who *think* they know, but
are not aware of such subtle points, could incorrectly assume
that removing the package is OK.
> The "real" bug here showed by diff (and a few other before)
> is therefore something like this:
> New essential package A replaces old essential package B.
> (Package B is now a transitional package to A.)
> The user (with mixed sources) tries to deinstall package B and
> apt refuses that as it thinks B is essential - it doesn't take into
> account that A provides the same functionality as B.
>
> Could we agree on that it is a (very) minor bug?
Yes.
--
Vincent Lefèvre <[email protected]> - 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)
Acknowledgement sent
to "Jesús M. Navarro" <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 20:42:04 GMT) (full text, mbox, link).
Subject: Re: Bug#216768: apt: Confirmed under Lenny with several sources and pinning
Date: Mon, 2 Nov 2009 21:32:34 +0100
Hi, David:
On Monday 02 November 2009 16:40:00 David Kalnischkies wrote:
> Hi all,
[...]
>
> The "real" bug here showed by diff (and a few other before)
> is therefore something like this:
> New essential package A replaces old essential package B.
> (Package B is now a transitional package to A.)
> The user (with mixed sources) tries to deinstall package B and
> apt refuses that as it thinks B is essential - it doesn't take into
> account that A provides the same functionality as B.
>
> Could we agree on that it is a (very) minor bug?
No. At least not a package bug. Your very reasonement about why all
essential packages are tried to be installed works here too: you have
packages from versions N and N+1 where packages on N depend on
essential "foo" and those on N+1 depend on the new essential "bar" which
overrides "foo". Then you can't gratuitously assume that even if "bar" is
functionally-wise the same as "foo" versions on N will in fact be able to
work with "bar": you don't know how many or how deep changes where needed on
N versions to make them work nicely with "bar" as they go N+1 (which it's, in
fact, the main function of the very distribution effort: manage to get a
disparaged bunch of packages to smoothly work together).
So I don't think that's a bug but an unsupported corner-case.
Acknowledgement sent
to Ivan Vilata i Balaguer <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 02 Nov 2009 20:54:15 GMT) (full text, mbox, link).
David Kalnischkies (el 2009-11-02 a les 16:40:00 +0100) va dir::
> A user who mixed sources very likely mixes also packages.
> As a package doesn't need to depend on essential packages,
> apt tries to install in a dist(ribution)-upgrade ALL essential
> packages it can find in all sources to protect the user from
> dependency hell and as a bonus protect the user from doing something
> stupid: Removing a package which is/was/will be essential as it is
> maybe required by package on this system (who know how far your
> mixing goes, so better save than sorry as Ivan Vilata i Balaguer also
> said indirectly in his second message).
Umm, I forgot to issue the dist-upgrade command after setting up the pinning,
and that's why the new essential packages weren't installed. However, running
``aptitude dist-upgrade`` doesn't install the new essential packages, while
``apt-get dist-upgrade`` does. Do you think I should report this as a bug in
Aptitude?
Thanks for your comments,
::
Ivan Vilata i Balaguer -- http://ivan.lovesgazpacho.net/
Acknowledgement sent
to Jonathan Nieder <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 17 Oct 2011 02:18:03 GMT) (full text, mbox, link).
Subject: Re: apt mixes essential flag from all sources
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. ;-)
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 17 Oct 2011 07:48:04 GMT) (full text, mbox, link).
Subject: Re: Bug#216768: apt mixes essential flag from all sources
Date: Mon, 17 Oct 2011 09:44:54 +0200
On 2011-10-16 21:15:15 -0500, Jonathan Nieder wrote:
> 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. ;-)
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 protected]> - 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)