Debian Bug report logs - #544481
[apt] apt mixes essential flag from all sources

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: diff should not be an essential package

Date: Mon, 31 Aug 2009 23:35:00 +0200

Package: diff
Version: 1:2.8.1-16
Severity: normal

The description of diff says:

Description: dummy transitional package for diff -> diffutils
 This is a dummy package to aid in transitioning from diff to diffutils.
 It may be safely removed after upgrading to squeeze.

(from "dpkg -s diff") and the package contains nothing except in
/usr/share/doc/diff. But apt-get doesn't want to remove it:

# apt-get remove diff
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  diff
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  diff
0 upgraded, 0 newly installed, 1 to remove and 13 not upgraded.
After this operation, 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!'
 ?]

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages diff depends on:
ii  diffutils                     1:2.8.1-16 File comparison utilities

diff recommends no packages.

diff suggests no packages.

-- no debconf information

Message #10 received at [email protected] (full text, mbox, reply):

From: Santiago Vila <[email protected]>

To: Vincent Lefevre <[email protected]>, [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 00:50:15 +0200 (CEST)

On Mon, 31 Aug 2009, Vincent Lefevre wrote:

> Package: diff
> Version: 1:2.8.1-16
> Severity: normal
> 
> The description of diff says:
> 
> Description: dummy transitional package for diff -> diffutils
>  This is a dummy package to aid in transitioning from diff to diffutils.
>  It may be safely removed after upgrading to squeeze.
> 
> (from "dpkg -s diff") and the package contains nothing except in
> /usr/share/doc/diff. But apt-get doesn't want to remove it:
> 
> # apt-get remove diff
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> The following packages will be REMOVED:
>   diff
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
>   diff

For FSM's sake, please use the source, Luke:

apt-get source diffutils
cd diffutils-2.8.1/
less debian/control

The diff dummy package is NOT essential. Only the diff package that
you installed from experimental a lot of time ago.

Obviously, if you remove experimental from sources.list, then apt-get
clearly will NOT upgrade essential diff 2.8.7 to dummy diff 2.8.1 in unstable
"so that your diff package is smoothly renamed to diffutils",
as 2.8.7 > 2.8.1.

If you installed something from experimental, deal with it, and be
ready to fix what's broken, specially if you then REMOVED experimental
from sources.list.

Message #15 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Santiago Vila <[email protected]>

Cc: [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 01:43:27 +0200

reopen 544481
thanks

On 2009-09-01 00:50:15 +0200, Santiago Vila wrote:
> For FSM's sake, please use the source, Luke:
> 
> apt-get source diffutils
> cd diffutils-2.8.1/
> less debian/control
> 
> The diff dummy package is NOT essential. Only the diff package that
> you installed from experimental a lot of time ago.

No, I've *never* installed diff from experimental on *this* machine
(which is not the same one as for bug 544480). The following versions
where installed:

2009-06-04 13:58:00 install diff <none> 2.8.1-12
2009-06-04 13:58:00 status half-installed diff 2.8.1-12
2009-06-04 13:58:00 status unpacked diff 2.8.1-12
2009-06-04 13:58:00 status unpacked diff 2.8.1-12
2009-06-04 13:58:03 configure diff 2.8.1-12 2.8.1-12
2009-06-04 13:58:03 status unpacked diff 2.8.1-12
2009-06-04 13:58:03 status half-configured diff 2.8.1-12
2009-06-04 13:58:03 status installed diff 2.8.1-12
2009-06-04 19:15:48 upgrade diff 2.8.1-12 2.8.1-13
2009-06-04 19:15:48 status half-configured diff 2.8.1-12
2009-06-04 19:15:48 status unpacked diff 2.8.1-12
2009-06-04 19:15:48 status half-installed diff 2.8.1-12
2009-06-04 19:15:48 status half-installed diff 2.8.1-12
2009-06-04 19:15:48 status half-installed diff 2.8.1-12
2009-06-04 19:15:49 status unpacked diff 2.8.1-13
2009-06-04 19:15:49 status unpacked diff 2.8.1-13
2009-06-04 19:15:50 configure diff 2.8.1-13 2.8.1-13
2009-06-04 19:15:50 status unpacked diff 2.8.1-13
2009-06-04 19:15:50 status half-configured diff 2.8.1-13
2009-06-04 19:15:50 status installed diff 2.8.1-13
2009-08-31 23:14:06 upgrade diff 2.8.1-13 1:2.8.1-16
2009-08-31 23:14:06 status half-configured diff 2.8.1-13
2009-08-31 23:14:06 status unpacked diff 2.8.1-13
2009-08-31 23:14:06 status half-installed diff 2.8.1-13
2009-08-31 23:14:06 status half-installed diff 2.8.1-13
2009-08-31 23:14:07 configure diff 1:2.8.1-16 1:2.8.1-16
2009-08-31 23:14:07 status unpacked diff 1:2.8.1-16
2009-08-31 23:14:07 status half-configured diff 1:2.8.1-16
2009-08-31 23:14:07 status installed diff 1:2.8.1-16

I installed the machine on 2009-06-04 from Debian/lenny, then
upgraded to unstable. On 2009-08-31, I used aptitude to upgrade
diff (and this was this version that was essential). Though
I have experimental in my sources, it has a lower precedence.

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

Message #22 received at [email protected] (full text, mbox, reply):

From: Santiago Vila <[email protected]>

To: Vincent Lefevre <[email protected]>

Cc: [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 02:27:33 +0200 (CEST)

On Tue, 1 Sep 2009, Vincent Lefevre wrote:

> reopen 544481
> thanks

Nonsense.

Is I said, and you can check from the source, the diff dummy packahge
is not essential anymore.

What exactly do you expect me to do with a bug saying "diff should not
be essential", when it already is *not*?

I could help you to determine what's wrong in your system, but *not*
on the basis that I have to do something that I've *already* done, namely,
dropping the Essential flag from the diff package.

Message #27 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Santiago Vila <[email protected]>

Cc: [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 02:55:18 +0200

reassign 544481 aptitude
severity 544481 critical
retitle 544481 aptitude installed non-essential diff 2.8.1-16 as essential
thanks

On 2009-09-01 02:27:33 +0200, Santiago Vila wrote:
> Nonsense.
> 
> Is I said, and you can check from the source, the diff dummy packahge
> is not essential anymore.
> 
> What exactly do you expect me to do with a bug saying "diff should not
> be essential", when it already is *not*?
> 
> I could help you to determine what's wrong in your system, but *not*
> on the basis that I have to do something that I've *already* done, namely,
> dropping the Essential flag from the diff package.

Then this means that aptitude (or dpkg?) broke my system.

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

Message #40 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Santiago Vila <[email protected]>

Cc: [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 03:02:46 +0200

reassign 544481 dpkg
thanks

On 2009-09-01 02:55:18 +0200, Vincent Lefevre wrote:
> reassign 544481 aptitude
> severity 544481 critical
> retitle 544481 aptitude installed non-essential diff 2.8.1-16 as essential
> thanks
> 
> On 2009-09-01 02:27:33 +0200, Santiago Vila wrote:
> > Nonsense.
> > 
> > Is I said, and you can check from the source, the diff dummy packahge
> > is not essential anymore.
> > 
> > What exactly do you expect me to do with a bug saying "diff should not
> > be essential", when it already is *not*?
> > 
> > I could help you to determine what's wrong in your system, but *not*
> > on the basis that I have to do something that I've *already* done, namely,
> > dropping the Essential flag from the diff package.
> 
> Then this means that aptitude (or dpkg?) broke my system.

Actually, I have the same problem after reinstalling diff with apt-get
(on a different machine). So, this probably comes from dpkg.

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

Message #47 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Vincent Lefevre <[email protected]>

Cc: Santiago Vila <[email protected]>, [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 08:52:26 +0200

reassing 544481 apt 0.7.23.1
severity 544481 normal
retitle 544481 apt mixes essential flag from all sources

On Tue, 01 Sep 2009, Vincent Lefevre wrote:
> > > I could help you to determine what's wrong in your system, but *not*
> > > on the basis that I have to do something that I've *already* done, namely,
> > > dropping the Essential flag from the diff package.
> > 
> > Then this means that aptitude (or dpkg?) broke my system.
> 
> Actually, I have the same problem after reinstalling diff with apt-get
> (on a different machine). So, this probably comes from dpkg.

What makes you believe so?

$ dpkg -s diff
Package: diff
Status: install ok installed
Priority: extra
Section: oldlibs
Installed-Size: 32
Maintainer: Santiago Vila <[email protected]>
Architecture: all
Source: diffutils
Version: 1:2.8.1-16
Depends: diffutils
Description: dummy transitional package for diff -> diffutils
 This is a dummy package to aid in transitioning from diff to diffutils.
 It may be safely removed after upgrading to squeeze.

=> no essential flag, dpkg removed it as expected...

IMO it's apt that simply mixes the Essential: flag read from different
sources, a quick check makes it obvious:

┏rivendell:~/x/git/dpkg (master)
┗(731)$ grep "deb " /etc/apt/sources.list
deb http://localhost:9999/security lenny/updates main
deb http://localhost:9999/security squeeze/updates main
deb http://localhost:9999/debian unstable main contrib non-free
deb http://localhost:9999/debian squeeze main contrib non-free
deb http://localhost:9999/debian lenny main contrib non-free
deb http://localhost:9999/debian experimental main contrib non-free
#deb http://kernel-archive.buildserver.net/debian-kernel trunk main
#deb http://download.tuxfamily.org/dvorak/debian sid main
#deb http://security.debian.org/ lenny/updates main
┏rivendell:~/x/git/dpkg (master)
┗(732)$ LANG=C sudo apt-get remove diff
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  diff
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  diff
0 upgraded, 0 newly installed, 1 to remove and 59 not upgraded.
After this operation, 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!'
 ?] ^C
┏rivendell:~/x/git/dpkg (master)
┗(733)$ sudo vim /etc/apt/sources.list
┏rivendell:~/x/git/dpkg (master)
┗(734)$ grep "deb " /etc/apt/sources.list
#deb http://localhost:9999/security lenny/updates main
#deb http://localhost:9999/security squeeze/updates main
deb http://localhost:9999/debian unstable main contrib non-free
#deb http://localhost:9999/debian squeeze main contrib non-free
#deb http://localhost:9999/debian lenny main contrib non-free
#deb http://localhost:9999/debian experimental main contrib non-free
#deb http://kernel-archive.buildserver.net/debian-kernel trunk main
#deb http://download.tuxfamily.org/dvorak/debian sid main
#deb http://security.debian.org/ lenny/updates main
┏rivendell:~/x/git/dpkg (master)
┗(735)$ LANG=C sudo apt-get remove diff
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  diff
0 upgraded, 0 newly installed, 1 to remove and 59 not upgraded.
After this operation, 32.8kB disk space will be freed.
Do you want to continue [Y/n]? ^C

So reassiging to apt... apt should use the essential flag from
/var/lib/dpkg/status / the distribution containing the installed package to
decide whether an essential package can be removed or not.

I also fail to see why this bug would be critical, the set of essential
packages doesn't change often and having to keep around the transitional
package is not a big deal.

Cheers,
-- 
Raphaël Hertzog

Message #60 received at [email protected] (full text, mbox, reply):

From: Sven Joachim <[email protected]>

To: Raphael Hertzog <[email protected]>

Cc: [email protected], Vincent Lefevre <[email protected]>, Santiago Vila <[email protected]>

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 01 Sep 2009 09:18:02 +0200

package apt
merge 216768 544481
thanks

On 2009-09-01 08:52 +0200, Raphael Hertzog wrote:

> reassing 544481 apt 0.7.23.1
> severity 544481 normal
> retitle 544481 apt mixes essential flag from all sources
> [...]
> IMO it's apt that simply mixes the Essential: flag read from different
> sources, a quick check makes it obvious:

This seems to have been reported several times already, see #216768 and
siblings.

> So reassiging to apt... apt should use the essential flag from
> /var/lib/dpkg/status / the distribution containing the installed package to
> decide whether an essential package can be removed or not.

Even if it did that it, is not clear to me whether it would not want to
reinstall it afterwards.  Bug #177952 seems to indicate that.

Sven

Message #67 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Raphael Hertzog <[email protected]>

Cc: Santiago Vila <[email protected]>, [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 09:59:17 +0200

On 2009-09-01 08:52:26 +0200, Raphael Hertzog wrote:
> IMO it's apt that simply mixes the Essential: flag read from different
> sources, a quick check makes it obvious:

OK, this is probably the reason (I confirm that dpkg removes diff,
and the fact I have the stable source, where diff is essential).

> I also fail to see why this bug would be critical, the set of essential
> packages doesn't change often and having to keep around the transitional
> package is not a big deal.

I thought that dpkg was corrupting some database internally under
some conditions. The message is very misleading, and I would have
never thought that apt would use the Essential flag from other
sources (this seems completely unnatural to me and this is the
first time I see something like that). BTW, if this bug cannot be
fixed now, perhaps in the mean time, the warning message could be
improved in order to be less misleading (e.g. saying that this
warning may be incorrect if there are other sources).

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

Message #72 received at [email protected] (full text, mbox, reply):

From: Santiago Vila <[email protected]>

To: Raphael Hertzog <[email protected]>

Cc: Vincent Lefevre <[email protected]>, [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 10:50:37 +0200 (CEST)

On Tue, 1 Sep 2009, Raphael Hertzog wrote:

> reassing 544481 apt 0.7.23.1
> severity 544481 normal
> retitle 544481 apt mixes essential flag from all sources

Thanks, Raphael. This is clearly a problem in apt.

> I also fail to see why this bug would be critical, the set of essential
> packages doesn't change often and having to keep around the transitional
> package is not a big deal.

Exactly.

Note to Vincent: Please do not overinflate bug severities.

Clearly, apt-get currently considers a package essential as far as
there is *some* essential package with that name available in any of
the sources.list lines.

As a result, you can't currently remove the dummy diff package, but
what is the real harm of not being able to remove a dummy package?
That's a bug like any other, not a critical one.

Another way of looking at that would be this one:

The description of diff now says that "you can remove it after
upgrading to squeeze". The dummy diff package is not in testing yet,
so this is naturally to be read by lenny users who upgrade to squeeze
once the new diff and diffutils packages reach testing.

However, I would not consider that you have "upgraded to squeeze" if you
still keep lenny lines in your sources.list.

The diff package is dummy for the benefit of people who do not want
any leftover of lenny in the system when they upgrade to squeeze.

So, if you don't want any leftover of lenny, consider removing lenny
from your sources.list.

Message #77 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Santiago Vila <[email protected]>

Cc: Raphael Hertzog <[email protected]>, [email protected]

Subject: Re: Bug#544481: diff should not be an essential package

Date: Tue, 1 Sep 2009 12:35:47 +0200

On 2009-09-01 10:50:37 +0200, Santiago Vila wrote:
> Note to Vincent: Please do not overinflate bug severities.

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.

> Clearly, apt-get currently considers a package essential as far as
> there is *some* essential package with that name available in any of
> the sources.list lines.
> 
> As a result, you can't currently remove the dummy diff package, but
> what is the real harm of not being able to remove a dummy package?
> That's a bug like any other, not a critical one.
> 
> Another way of looking at that would be this one:
> 
> The description of diff now says that "you can remove it after
> upgrading to squeeze". The dummy diff package is not in testing yet,
> so this is naturally to be read by lenny users who upgrade to squeeze
> once the new diff and diffutils packages reach testing.

Would this make any difference? IMHO there would be the same problem
even for stable, for users who have both lenny (where diff is
essential) and squeeze in their source.

> However, I would not consider that you have "upgraded to squeeze" if
> you still keep lenny lines in your sources.list.

AFAIK, users are allowed to just add squeeze lines and keep lenny
lines in their sources.list. At least apt-get wouldn't complain,
would it?

> The diff package is dummy for the benefit of people who do not want
> any leftover of lenny in the system when they upgrade to squeeze.
> 
> So, if you don't want any leftover of lenny, consider removing lenny
> from your sources.list.

Packages (whether in unstable or stable) gets sometimes broken or
removed, so that keeping lenny may be useful (well, at least a short
time after an upgrade, which is probably no longer the case).

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

Message #86 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Ivan Vilata i Balaguer <[email protected]>, Vincent Lefevre <[email protected]>, Santiago Vila <[email protected]>, [email protected]

Cc: [email protected], Raphael Hertzog <[email protected]>

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

Message #91 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: Ivan Vilata i Balaguer <[email protected]>, Santiago Vila <[email protected]>, [email protected], [email protected], Raphael Hertzog <[email protected]>

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)

Message #96 received at [email protected] (full text, mbox, reply):

From: Ivan Vilata i Balaguer <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: Ivan Vilata i Balaguer <[email protected]>, Vincent Lefevre <[email protected]>, Santiago Vila <[email protected]>, [email protected], [email protected], Raphael Hertzog <[email protected]>

Subject: Re: Bug#216768: apt: Confirmed under Lenny with several sources and pinning

Date: Mon, 2 Nov 2009 21:10:14 +0100

[Message part 1 (text/plain, inline)]

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/

[signature.asc (application/pgp-signature, inline)]

Message #105 received at [email protected] (full text, mbox, reply):

From: Matt Taggart <[email protected]>

To: [email protected], [email protected]

Cc: [email protected], [email protected], [email protected], [email protected]

Subject: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Wed, 28 Apr 2010 00:23:03 -0700

Like the reporters of #531002 and #557209 I was seeing apticron continually 
reporting that the dash and diffutils packages needed to be upgraded. I 
figured out what is going on:

1) The systems seeing this also have unstable listed in sources.list but 
have it pinned to a low priority.
2) diffutils and dash are "Priority: required"/"Essential: yes" in 
unstable, but weren't in lenny.
3) apt-get dist-upgrade thinks they should be pulled in (aptitude 
dist-upgrade ignores them)

This appears to be the same as #544481.

For apticron: can this be worked around or maybe just document ways the 
user can prevent it from happening?

For apt-get:
I suppose this could be seen as either a bug or feature, if the latter then 
please leave open and tag wontfix (and make aptitude consistent). 
Regardless of the default, it might be nice to have a command-line switch 
that controls the behavior so that things like apticron could specify what 
they want.

-- 
Matt Taggart
[email protected]

Message #110 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Matt Taggart <[email protected]>, 544481 <[email protected]>

Cc: 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Wed, 28 Apr 2010 21:14:52 +0200

Hi .*,

2010/4/28 Matt Taggart <[email protected]>:
> 2) diffutils and dash are "Priority: required"/"Essential: yes" in
> unstable, but weren't in lenny.
Every time we talk about the "problem" outlined here it boils down to:
Why the user still have the (old)stable repository in his sources?

If (s)he has no package left from this old archive it is as obsolete as the
now obsolete transition packages (s)he want to remove.

If (s)he still have packages from this old archive (s)he needs all essentials
from this archive as otherwise the packages could be broken
(they all depend implicitly on the essential packages).

> 3) apt-get dist-upgrade thinks they should be pulled in (aptitude
> dist-upgrade ignores them)
Software can't easily tell if a package is left from the old archive, so
apt-get chooses the "better safe than sorry"-approach.
Other package manager (front-ends) choose a different approach.


The most common annoyance with the apt-approach is a package rename,
as can be seen in #544481 and friends -- can be easily fixed by the user
with removing the obsolete source and/or by the project with a
"package A replaces package B functional complete" semantic.
(Replaces tell us only that a few files are replaced, Conflict+Provides+
Replaces doesn't work as we have a short timeframe in which no installed
package provides the functionality, which is a no-go for essential packages)

One counterexample is e.g.:
Imagine perl-base will be dropped from the essential set:
A user upgrades his perl stuff but keeps the rest in oldstable.
Calling an orphanfinder application will quickly show perl-base as
no longer needed so (s)he thinks it can be removed.
After that all old packages which depend on the fact that the
package was essential and therefore doesn't explicitly depend on it
are now broken - which includes parts of dpkg btw.

We can argue now that mixed systems aren't supported, but in the
middle of a dist-upgrade from old-stable to stable the system is also
a mixed system -- and, if we really would not support it, why does the
user have different archives in his sources?


> For apticron: can this be worked around or maybe just document ways the
> user can prevent it from happening?
By popular depend (or by us for debugging proposes) is a little cheat option
implemented in apt (currently only in experimental) which can control the
essential flag:
pkgCacheGen::Essential=all|native|installed|none
(you need to build the cache with this option!)
I do not recommend to use nor do i will support the usage of this option
(and because of that it is also not documented) but some people really
thing it is important, so i don't want to stay in their way to break their
system if they really want to do that, as i am bored by the whole discussion
for a long while now - especially because this discussion generated far more
mails than debian includes essential packages… I really thing we have
better things to do than thinking about transition handling for ~30 packages…

> For apt-get:
> I suppose this could be seen as either a bug or feature, if the latter then
> please leave open and tag wontfix (and make aptitude consistent).
I don't like tag and severity ping pong and i am pretty sure this will happen
as the frontline between bug and feature is quite large and everyone
has its own opinion which is crystal clear and obviously right, e.g. [0].

aptitude is pretty independent from apt and can make decisions on his own.
If aptitude would be consistent to apt in all his solutions you would not need
one of the two… choose the tool which suites you best.

> Regardless of the default, it might be nice to have a command-line switch
> that controls the behavior so that things like apticron could specify what
> they want.
As said, such an option will exist in the future - but i don't think it is a
good idea to be used by an other application as this will lead to the
situation that apticron output differs from the "normal" output apt has and
therefore confuses the user without (good) reason -- but i don't know how
the output looks like and how the information is acquired,
so i am maybe wrong.
(beside that it needs more than the option to force a rebuild and after that
need to rebuild the cache again without the option enabled for the user -
and it overrides user configuration if the user has set the option already…
It would be similar but less visible to using -t experimental in apticron)

If the user don't want to see it (s)he can e.g. put the not installed
package on hold and will be done with it…


Best non-essential regards,

David Kalnischkies

[0] http://lists.debian.org/deity/2010/01/msg00088.html

Message #115 received at [email protected] (full text, mbox, reply):

From: Toni Mueller <[email protected]>

To: David Kalnischkies <[email protected]>, [email protected]

Cc: Matt Taggart <[email protected]>, 544481 <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#557209: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Wed, 28 Apr 2010 21:39:38 +0200

Hi,

On Wed, 28.04.2010 at 21:14:52 +0200, David Kalnischkies <[email protected]> wrote:
> 2010/4/28 Matt Taggart <[email protected]>:
> > 2) diffutils and dash are "Priority: required"/"Essential: yes" in
> > unstable, but weren't in lenny.
> Every time we talk about the "problem" outlined here it boils down to:
> Why the user still have the (old)stable repository in his sources?

this is easy to answer: Some people, like me, run a mostly stable
system, but need a few bits from up to unstable, ***NOT*** the other
way round, as you suggest.

> If (s)he has no package left from this old archive it is as obsolete as the
> now obsolete transition packages (s)he want to remove.

We're talking about stable, not oldstable, here. So please calm down
instead of flaming users for running "obsolete" stuff. Also, the
package handling should be easy enough for users who are not deities
themselves.

> If the user don't want to see it (s)he can e.g. put the not installed
> package on hold and will be done with it?

This does not seem to work in all cases. I've recently struggled with a
system that was trying to remove or upgrade packages that I had
explicitly set on hold immediately before. But I made no recordings,
so...


Kind regards,
--Toni++

Message #120 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Toni Mueller <[email protected]>, 544481 <[email protected]>

Cc: 557209-quiet <[email protected]>, Matt Taggart <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#544481: Bug#557209: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Wed, 28 Apr 2010 23:33:39 +0200

2010/4/28 Toni Mueller <[email protected]>:
> On Wed, 28.04.2010 at 21:14:52 +0200, David Kalnischkies <[email protected]> wrote:
>> 2010/4/28 Matt Taggart <[email protected]>:
>> > 2) diffutils and dash are "Priority: required"/"Essential: yes" in
>> > unstable, but weren't in lenny.
>> Every time we talk about the "problem" outlined here it boils down to:
>> Why the user still have the (old)stable repository in his sources?
>
> this is easy to answer: Some people, like me, run a mostly stable
> system, but need a few bits from up to unstable, ***NOT*** the other
> way round, as you suggest.

Sorry if this sounded rude - it wasn't meant that way. I had a conversion
with Matt Taggart on the IRC before and it seems i interpreted it later in the
way the "problem" is normally raised:
"I have upgraded from oldstable to stable and can't remove old-essentials."
My bad.

>> If (s)he has no package left from this old archive it is as obsolete as the
>> now obsolete transition packages (s)he want to remove.
>
> We're talking about stable, not oldstable, here. So please calm down
> instead of flaming users for running "obsolete" stuff. Also, the
> package handling should be easy enough for users who are not deities
> themselves.

I really hope that not everyone is a deity who is able to handle packages as
this would at least in my culture mean that we have only a single person/deity
with this ability. ;)

It is exactly my point that the user shouldn't worry about dependencies and
essentials are a special case of dependencies. I am mostly confronted
with the situation i described above with the obsolete (for their
setup) archives
so i referred to this situation - as i said in this situation no
package is left,
so the archive is really obsolete and can be removed from the sources, which
leads also to the point the old essentials are not longer consider as
old essentials.

But your case of mostly stable with a few unstable packages has obviously
nothing to do with obsolete archives. It is only that in this case the message
is even more correct as your unstable packages could depend on an essential
from unstable which is not in stable - or not with this name and/or
functionality.

So apt chooses the paranoid way and consider old, new and current essentials
as essentials so the user doesn't run into problems (s)he would maybe face
otherwise. It is therefore meant as a simplification as i guess nobody
really want
to check for every new package if it included implicit dependencies on
an essential
package… (in your case dash for example)

>> If the user don't want to see it (s)he can e.g. put the not installed
>> package on hold and will be done with it?
>
> This does not seem to work in all cases. I've recently struggled with a
> system that was trying to remove or upgrade packages that I had
> explicitly set on hold immediately before. But I made no recordings,
> so...

At least for apt this should not happen: A dpkg hold can only be
overridden by the
user with a direct install request (or the > 1000 pinning). aptitude
uses his own
hold mechanism and is not as strict, so you have maybe mixed the two?
If you can find some records or encounter it again, i would be happy
if you could
report it.


Best regards,

David Kalnischkies

Message #125 received at [email protected] (full text, mbox, reply):

From: Matt Taggart <[email protected]>

To: Toni Mueller <[email protected]>

Cc: David Kalnischkies <[email protected]>, Matt Taggart <[email protected]>, 544481 <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#557209: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Wed, 28 Apr 2010 22:04:27 -0700

> > If the user don't want to see it (s)he can e.g. put the not installed
> > package on hold and will be done with it?
> 
> This does not seem to work in all cases. I've recently struggled with a
> system that was trying to remove or upgrade packages that I had
> explicitly set on hold immediately before. But I made no recordings,
> so...

Here's a specific example, the two packages in question in the apticron 
bugs:

1) dash - I didn't have it installed to begin with, but I was able to 
install the stable version and put it on hold and that prevented 
dist-upgrade from wanting to upgrade it.

2) diffutils - This didn't exist as a binary package in stable, so there is 
nothing to install and put on hold. On #debian-backports we discussed the 
idea of backporting the testing version with "Essential: yes" removed (and 
converted to the old source format so it will work with backports). I might 
do that soon.

-- 
Matt Taggart
[email protected]

Message #130 received at [email protected] (full text, mbox, reply):

From: Matt Taggart <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: Matt Taggart <[email protected]>, 544481 <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Wed, 28 Apr 2010 22:18:51 -0700

> We can argue now that mixed systems aren't supported, but in the
> middle of a dist-upgrade from old-stable to stable the system is also
> a mixed system -- and, if we really would not support it, why does the
> user have different archives in his sources?

I have often seen package maintainers suggest just using a package from 
testing or unstable on stable systems when it is known to work (the 
dependencies work and it's expected to function) rather than backport 
packages. For example: this is the standard recommendation of the 
debian-kernel team when someone wants a newer kernel on their stable system.

> aptitude is pretty independent from apt and can make decisions on his own.

Well that might be true, but they are both part of Debian and while this 
behavior isn't something you'd expect to be defined in debian policy, I 
think users would expect them to function the same where possible.

> As said, such an option will exist in the future - but i don't think it is a
> good idea to be used by an other application as this will lead to the
> situation that apticron output differs from the "normal" output apt has and
> therefore confuses the user without (good) reason -- but i don't know how
> the output looks like and how the information is acquired,
> so i am maybe wrong.

apticron is designed run "apt-get -s dist-upgrade" once a day and if there 
are packages pending then send mail to root with a report. Because of the 
current apt-get behavior it means root gets email every day, despite the 
system up to date with stable.

Can you think of another way that apticron could determine if things are 
needed? Or possibly a work around that people using mixed sources could 
use? (like something in preferences perhaps)

Thanks,

-- 
Matt Taggart
[email protected]

Message #135 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Matt Taggart <[email protected]>

Cc: 544481 <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Thu, 29 Apr 2010 08:55:58 +0200

2010/4/29 Matt Taggart <[email protected]>:
> Can you think of another way that apticron could determine if things are
> needed?

That is the point: We disagree here if the listed packages are need or not.

In a complete upgraded stable from oldstable the old essentials are not
needed so they can be removed which apt just forbids because of the
oldstable archive still in the sources - if the sources entry is gone the
packages can also go.

In a system which is mostly stable with a few unstable packages you
have a) essentials which are only essentials in stable: You need these
as your packages from stable implicit depend on them, but you need
also b) the essentials from unstable as your packages from unstable
depend on them implicitly. Just imagine an unstable package needs
dash to function correctly: Normally it would have a Depends on dash,
but as dash is in unstable an essential package it will NOT have a
dependency on dash - it will just assume that dash is installed.

So my take is that these packages apticron lists here are needed -
you have until now just enough luck that your system works without
them as no unstable package made use of dash but the next install
could change that… (or even remove as the dash dependency could
be also in a {pre,post}rm script… - pre as essentials work also in
unpack state and are never uninstalled).

The fact that it is a bit unlikely that your system will break next time
is just that most new-essentials are renamed old-essentials or are
e.g. in the case of dash essential as a shell but not really used by
a package itself -- but you can never be sure…


Best regards,

David Kalnischkies

Message #140 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Matt Taggart <[email protected]>, 544481 <[email protected]>

Cc: Toni Mueller <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#544481: Bug#557209: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Thu, 29 Apr 2010 09:15:00 +0200

2010/4/29 Matt Taggart <[email protected]>:
> 2) diffutils - This didn't exist as a binary package in stable, so there is
> nothing to install and put on hold.
You can put a hold even on a not installed package, so you can use a hold
also to prevent the installation of the package, not only the upgrade of the
package. (Just make sure to release the holds before the next stable
upgrade as it will have "funny" effects otherwise…)

> On #debian-backports we discussed the
> idea of backporting the testing version with "Essential: yes" removed (and
> converted to the old source format so it will work with backports). I might
> do that soon.
I guess this will be difficult. In unstable diff is a transition package and
diffutils contain the "diff" functionality. In stable diffutils
doesn't exist and
diff has the "diff" functionality.
Unstable diff pre-depends on diffutils.

If you now add something to backport you either need to forward the
transition (= upload diff and diffutils) or upload diffutils as a dummy
package -- but this will break the pre-depends for upgraders later on
as the unstable diff (dummy) can be unpacked before the diffutils package
from unstable is unpacked (and configured) as a package with
this name is already installed and satisfy this dependency, but it
is also a dummy package, so you have created a timeframe in
which no package provides the diff functionality…
The solution is a versioned pre-depends, but i am not sure if this
is worthed the hassle…


Best regards,

David Kalnischkies

Message #145 received at [email protected] (full text, mbox, reply):

From: Goswin von Brederlow <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: [email protected], Matt Taggart <[email protected]>, 531002 <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Thu, 29 Apr 2010 15:01:14 +0200

David Kalnischkies <[email protected]> writes:

> Hi .*,
>
> 2010/4/28 Matt Taggart <[email protected]>:
>> 2) diffutils and dash are "Priority: required"/"Essential: yes" in
>> unstable, but weren't in lenny.
> Every time we talk about the "problem" outlined here it boils down to:
> Why the user still have the (old)stable repository in his sources?
>
> If (s)he has no package left from this old archive it is as obsolete as the
> now obsolete transition packages (s)he want to remove.
>
> If (s)he still have packages from this old archive (s)he needs all essentials
> from this archive as otherwise the packages could be broken
> (they all depend implicitly on the essential packages).

You have the problem backward in this case.

The user has stable with a few select packages from unstable. Unstable
is pinned down so the default remains stable. In UNSTABLE diffutils and
dash are essential but in stable they are not and they are not
installed.

But you are also right. If even one package from unstable is installed
then everything essential from unstable must be installed because that
one package may depend on it being there.

>> 3) apt-get dist-upgrade thinks they should be pulled in (aptitude
>> dist-upgrade ignores them)
> Software can't easily tell if a package is left from the old archive, so
> apt-get chooses the "better safe than sorry"-approach.
> Other package manager (front-ends) choose a different approach.

If by "old" you mean lesser pinned then yes.

>> For apticron: can this be worked around or maybe just document ways the
>> user can prevent it from happening?
> By popular depend (or by us for debugging proposes) is a little cheat option
> implemented in apt (currently only in experimental) which can control the
> essential flag:
> pkgCacheGen::Essential=all|native|installed|none
> (you need to build the cache with this option!)
> I do not recommend to use nor do i will support the usage of this option
> (and because of that it is also not documented) but some people really
> thing it is important, so i don't want to stay in their way to break their
> system if they really want to do that, as i am bored by the whole discussion
> for a long while now - especially because this discussion generated far more
> mails than debian includes essential packages… I really thing we have
> better things to do than thinking about transition handling for ~30 packages…

And most cases aren't about a transition but about maintaining a mixed setup.
And in a mixed setup the essential debs from all releases must be
installed.

MfG
        Goswin

Message #150 received at [email protected] (full text, mbox, reply):

From: Tiago Bortoletto Vaz <[email protected]>

To: Goswin von Brederlow <[email protected]>, [email protected]

Cc: David Kalnischkies <[email protected]>, [email protected], Matt Taggart <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#531002: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Thu, 13 May 2010 03:54:48 +0000

Hi all,

On Thu, Apr 29, 2010 at 03:01:14PM +0200, Goswin von Brederlow wrote:
> David Kalnischkies <[email protected]> writes:
[...]
> >> For apticron: can this be worked around or maybe just document ways the
> >> user can prevent it from happening?
> > By popular depend (or by us for debugging proposes) is a little cheat option
> > implemented in apt (currently only in experimental) which can control the
> > essential flag:
> > pkgCacheGen::Essential=all|native|installed|none
> > (you need to build the cache with this option!)
> > I do not recommend to use nor do i will support the usage of this option
> > (and because of that it is also not documented) but some people really
> > thing it is important, so i don't want to stay in their way to break their
> > system if they really want to do that, as i am bored by the whole discussion
> > for a long while now - especially because this discussion generated far more
> > mails than debian includes essential packages… I really thing we have
> > better things to do than thinking about transition handling for ~30 packages…
> 
> And most cases aren't about a transition but about maintaining a mixed setup.
> And in a mixed setup the essential debs from all releases must be
> installed.

From apticron side:

I support the opinion that once the user has testing/unstable repositories in a
stable system it's reasonable to consider installing the essential packages
from those Debian suites. So IMO the current issue is not a bug in apt-get.

However, from apticron's description:

"...sends daily emails about pending package updates such as security updates".

So, warning the user about how to proper handle other stuff in his/her mixed
system is not apticron's role. Also, sending emails about pending updates
related to packages which are not even installed is definitely a bug in
apticron because it makes user confused. But as it is not a grave bug and it's
a kind of exception caused by (IMO a feature, not a bug of) another tool, I
propose to insert a BUGS section in apticron's manpage explaining such issue,
pointing out this bug report and giving the user options (like puting packages
on hold or installing them) in order to avoid those annoying emails from
apticron.

What do you think?

Best regards and thanks for your time here,

-- 
--------------------------------------------------------------------------------
  .''`.  Tiago Bortoletto Vaz                         GPG  :      1024D/A504FECA
 : :' :  http://tiagovaz.org                          XMPP : tiago at jabber.org
 `. `'   tiago at {tiagovaz,debian}.org               IRC  :       tiago at OFTC
   `-    Debian GNU/Linux - The Universal OS               http://www.debian.org
--------------------------------------------------------------------------------

Message #155 received at [email protected] (full text, mbox, reply):

From: Goswin von Brederlow <[email protected]>

To: Tiago Bortoletto Vaz <[email protected]>

Cc: Goswin von Brederlow <[email protected]>, [email protected], David Kalnischkies <[email protected]>, [email protected], Matt Taggart <[email protected]>, 557209 <[email protected]>, 531002-submitter <[email protected]>, 557209-submitter <[email protected]>, alster <[email protected]>

Subject: Re: Bug#531002: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

Date: Thu, 13 May 2010 13:36:37 +0200

Tiago Bortoletto Vaz <[email protected]> writes:

> Hi all,
>
> On Thu, Apr 29, 2010 at 03:01:14PM +0200, Goswin von Brederlow wrote:
>> David Kalnischkies <[email protected]> writes:
> [...]
>> >> For apticron: can this be worked around or maybe just document ways the
>> >> user can prevent it from happening?
>> > By popular depend (or by us for debugging proposes) is a little cheat option
>> > implemented in apt (currently only in experimental) which can control the
>> > essential flag:
>> > pkgCacheGen::Essential=all|native|installed|none
>> > (you need to build the cache with this option!)
>> > I do not recommend to use nor do i will support the usage of this option
>> > (and because of that it is also not documented) but some people really
>> > thing it is important, so i don't want to stay in their way to break their
>> > system if they really want to do that, as i am bored by the whole discussion
>> > for a long while now - especially because this discussion generated far more
>> > mails than debian includes essential packages… I really thing we have
>> > better things to do than thinking about transition handling for ~30 packages…
>> 
>> And most cases aren't about a transition but about maintaining a mixed setup.
>> And in a mixed setup the essential debs from all releases must be
>> installed.
>
> From apticron side:
>
> I support the opinion that once the user has testing/unstable repositories in a
> stable system it's reasonable to consider installing the essential packages
> from those Debian suites. So IMO the current issue is not a bug in apt-get.
>
> However, from apticron's description:
>
> "...sends daily emails about pending package updates such as security updates".
>
> So, warning the user about how to proper handle other stuff in his/her mixed
> system is not apticron's role. Also, sending emails about pending updates
> related to packages which are not even installed is definitely a bug in
> apticron because it makes user confused. But as it is not a grave bug and it's
> a kind of exception caused by (IMO a feature, not a bug of) another tool, I
> propose to insert a BUGS section in apticron's manpage explaining such issue,
> pointing out this bug report and giving the user options (like puting packages
> on hold or installing them) in order to avoid those annoying emails from
> apticron.
>
> What do you think?
>
> Best regards and thanks for your time here,

Since not having the essential packages installed can cause random
breakage I think it is good to notify the user about it. Just explain it
better if you feel it is confusing.

MfG
        Goswin

Send a report that this bug log contains spam.