Le Mon, Nov 30, 2015 at 10:31:14PM +0900, Charles Plessy a écrit :
>
> I started a discussion on the debian-backports mailing list. Let's see how it
> goes.
>
> <https://lists.debian.org/debian-backports/2015/11/msg00067.html>
Hello everybody,
To summarise the original question:
some Debian Stable images prepared by us for some "cloud" systems contain a few
hand-picked packages from stable-backports (or from testing or unstable, in
which case the creation of a stable backport could be considered). To provide
a path for security and bug upgrades, the most straightforward way is to add
the stable-backports suite to APT's source list. This means that some users
may install backported packages without realising it. The Debian Backports
package states "Backports cannot be tested as extensively as Debian stable, and
backports are provided on an as-is basis, with risk of incompatibilities with
other components in Debian stable. Use with care!". Therefore, it is
controversial whether using and enabling Backports is appropriate for an image
that we call "Stable", and we wondered if something could be changed on APT's
side to prevent unintentional installation of backports.
First, let's recapitulate how APT installs backports.
The current behaviour of APT with the Backports suites is a logical consequence
of its design, and is actually not specific to backports. For instance,
similar phenomena can be observed with the "experimental" suite.
When the "install" command is called for a package, APT will consider the
versions available from the suites listed as APT data sources, plus the locally
installed package if any. Following some rules explained in the
apt_preferences manpage, each version receives a priority ("pin values"), and
APT will either install one of the highest-priority versions or do nothing.
Installing and upgrading a package are done with the same command ("install"),
following the same set of rules: from APT's point of view, there is no
conceptual difference. Likewise, there is nothing special about installing a
package from the backports suite without having selected it explicitely.
Thus, if a package in stable-backports has the highest priority, it will be
installed. The default priorities in backports suites are set to be lower than
the default priorities in stable suites, but if there is no package available
locally or from a stable suite, the backports can be the best valid candidate,
and therefore be installed.
About the user interface.
It is assumed that if the user typed "apt install foo", the user will be
satisfied with the installation of "foo". I think that this is a core point of
disagreement in the discussion on whether backports can be enabled by default
or not.
There is interest in the APT team to "make it (more) easy to rate a solution by
displaying more information". Depending on the user impact (including the fact
that they also use aptitude and other front-ends), this may open the way to
enable backports by default on stable systems. There is no timeline, but
obviously, contributions to APT development are most welcome.
In conclusion:
We are not going to enable backports by default in the short term, but I hope
that some readers, like me, strenghtened their understanding on how APT works.
Thanks everybody for following so far, and have a happy new year !
--
Charles
