Re: Cloud images with backports APT-enabled.
On Mon, Dec 28, 2015 at 9:19 AM, Charles Plessy <plessy@debian.org> wrote:
> 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
>
Charles, great summary! I'm now wondering if cloud-init might be a candidate
for "stable-updates"?
The criteria [1] are:
- The update is urgent and not of a security nature. Security updates
will continue to be pushed through the security archive. Examples
include packages broken by the flow of time (c.f. spamassassin and the
year 2010 problem) and fixes for bugs introduced by point releases.
- The package in question is a data package and the data must be
updated in a timely manner (e.g. tzdata).
- Fixes to leaf packages that were broken by external changes (e.g.
video downloading tools and tor).
- Packages that need to be current to be useful (e.g. clamav).
It seems to me that at least a couple of these criteria fit for cloud-init.
Thoughts?
-Brian
[1] - https://www.debian.org/News/2011/20110215
Reply to: