Hi,
On 2015-09-21 12:43:08 +0100, Manuel A. Fernandez Montecelo wrote:
> The website also says:
>
> http://www.debian.org/releases/
>
> unstable
>
> The unstable distribution is where active development of Debian
> occurs. Generally, this distribution is run by developers and those
> who like to live on the edge.
>
> And:
>
> http://www.debian.org/releases/sid/
>
> sid is subject to massive changes and in-place library updates. This
> can result in a very unstable system which contains packages that
> cannot be installed due to missing libraries, dependencies that cannot
> be fulfilled etc. Use it at your own risk!
Basically, two things are said:
1. Some packages cannot be installed (for some period), which is OK
for me, and this cannot be avoided.
2. Things may break due to active development, but I think that
everyone should agree that this should be regarded as a bug.
> According to the original bug message, you use unstable by default and
> experimental (also known as rc-buggy):
>
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 'experimental')
I've just enabled experimental, but it has priority 1, meaning that
such packages should never be installed automatically, as described
in apt_preferences(5). This is for APT, but I expect aptitude to
follow these rules. Unfortunately it doesn't and silently upgrades
packages to experimental; that's bug 795228.
> I am sure that you are aware about all of this. But in this case, you
> are also aware that upgrades not strictly from one stable to the next in
> Debian are not supported, much less mixing 4 distributions (with 3/4
> versions of each packages and multiple possibilities to conflict),
> including unstable and experimental at random points in time, including
> huge transitions between releases, as we have now (and this is like the
> worst time in a decade).
No, upgrades should still be supported as long as packages are in
official Debian repositories, and according to a recent discussion,
this should include upgrades from experimental.
> If I ask aptitude to upgrade a package and the dependencies cannot be
> fulfilled (as explained above for unstable), it is natural that aptitude
> tries to come up with weird solutions. That includes downgrading.
I disagree. It is natural that aptitude follows the apt_preferences(5)
rules by default, at least no automatic installation of experimental
packages (priority 1) and excluding downgrading except in specific
cases:
· Never downgrade unless the priority of an available version exceeds
1000. ("Downgrading" is installing a less recent version of a
package in place of a more recent version. Note that none of APT's
default priorities exceeds 1000; such high priorities can only be
set in the preferences file. Note also that downgrading a package
can be risky.)
By default, aptitude should just block the upgrade of packages that
don't satisfy the dependencies.
> To me, is a bit like assigning critical to dpkg because "dpkg -i
> ${random-deb}" also allows you to downgrade (without even asking!), or
> to coreutils because a mistaken "rm" can cause "accidental data loss"
> and doesn't even tell you which files it removed in the default config.
If both cases, that's a user fault (dpkg is a low-level tool,
contrary to APT and APT-based tools).
> >Aptitude::UI::Package-Display-Format "%c%a%M %p %Z %24v %24V";
> >Aptitude::ProblemResolver::SolutionCost "removals";
>
> According to the documentation, "removal" means: "Counts the number of
> packages that the solution removes".
>
> I assume that this works as intended and doesn't like solutions like
> removing obsolete libraries (of which there are lots lately, specially
> after the *v5 mass-renaming for example and with gcc-5 adding lots of
> "breaks" to some packages), so maybe it doesn't have better options (in
> terms of "resolver costs") than to downgrade.
No, the best solution is to require the user to solve the problem
manually. Well, I wish there were a way to remove libraries
automatically (since they are typically installed as dependencies),
but this doesn't seem to be possible with aptitude. And without
Aptitude::ProblemResolver::SolutionCost "removals";
aptitude sometimes wants to remove most of the system, making 'U'
in the UI completely useless!
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
