On Sun, 21 Mar 2010, David Kalnischkies wrote:
2010/3/21 Santiago Vila sanv...@unex.es:
This is a bug because, for example, once you upgrade an essential
package like the real diff to a non-essential one like the dummy diff,
the old essential package should not be considered essential
2010/3/22 Santiago Vila sanv...@unex.es:
On Sun, 21 Mar 2010, David Kalnischkies wrote:
2010/3/21 Santiago Vila sanv...@unex.es:
This is a bug because, for example, once you upgrade an essential
package like the real diff to a non-essential one like the dummy diff,
the old essential
On Mon, 22 Mar 2010, David Kalnischkies wrote:
I will further enlarge my example: Imagine you have a stable system with
perl-base essential and you install a perl application from testing which
also pulls in a newer non-essential perl-base. Remove the perl application
now and run autoremove
2010/3/22 Santiago Vila sanv...@unex.es:
See why I say that Essential: yes means do not remove me easily, not
install me if I'm not installed?
No, i don't see it.
Your remove is hard to do, but okay is absolutely not what essential says:
I as a package maintainer want to release a package X
On Mon, 22 Mar 2010, David Kalnischkies wrote:
2010/3/22 Santiago Vila sanv...@unex.es:
See why I say that Essential: yes means do not remove me easily, not
install me if I'm not installed?
No, i don't see it.
Your remove is hard to do, but okay is absolutely not what essential says:
On Sun, Mar 21, 2010 at 04:36:59AM +0100, Santiago Vila wrote:
Julian Andres Klode escribió:
forcemerge 177952 574729
thanks
On Sat, Mar 20, 2010 at 04:27:14PM +0100, Santiago Vila wrote:
Package: apt
Version: 0.7.25.3
It seems apt-get installs new essential packages by default.
This
On Sun, 21 Mar 2010, Julian Andres Klode wrote:
No, you are drawing conclusions that are not in policy. apt-get
would not violate policy, because policy does not say that apt-get
should try to fix the system.
It only tries it in dist-upgrade or when installing new packages;
and not on
On Sun, Mar 21, 2010 at 02:02:19PM +0100, Santiago Vila wrote:
On Sun, 21 Mar 2010, Julian Andres Klode wrote:
No, you are drawing conclusions that are not in policy. apt-get
would not violate policy, because policy does not say that apt-get
should try to fix the system.
It only
On Sun, 21 Mar 2010, Julian Andres Klode wrote:
On Sun, Mar 21, 2010 at 02:02:19PM +0100, Santiago Vila wrote:
Otherwise, changing the essential package set would
be a much more difficult thing.
No, that's not true, and I wrote specifically about this case in the
initial message for
2010/3/21 Santiago Vila sanv...@unex.es:
This is a bug because, for example, once you upgrade an essential
package like the real diff to a non-essential one like the dummy diff,
the old essential package should not be considered essential anymore,
even if it's available, i.e. it is the
Package: apt
Version: 0.7.25.3
It seems apt-get installs new essential packages by default.
This *is* a bug. Please let me explain why:
The purpose and meaning of the essential flag is, and it has always
been should not be removed, *not* should be installed by default.
Those two things might
forcemerge 177952 574729
thanks
On Sat, Mar 20, 2010 at 04:27:14PM +0100, Santiago Vila wrote:
Package: apt
Version: 0.7.25.3
It seems apt-get installs new essential packages by default.
This *is* a bug. Please let me explain why:
It is not, read Policy section 3.8:
Essential is defined
Julian Andres Klode escribió:
forcemerge 177952 574729
thanks
On Sat, Mar 20, 2010 at 04:27:14PM +0100, Santiago Vila wrote:
Package: apt
Version: 0.7.25.3
It seems apt-get installs new essential packages by default.
This *is* a bug. Please let me explain why:
It is not, read Policy section
13 matches
Mail list logo