Discussion:
LXD Official PPA deprecation
(too old to reply)
Jeff Kowalczyk
2017-12-27 16:57:03 UTC
Permalink
When updating LXD 2.20 on Ubuntu 16.04, I noticed the PPA deprecation
notice, included below [1].

I'd like to respectfully ask that the PPA not be deprecated and continue to
see new package versions. Or at the very least, see deprecation deferred
until after the next LTS 18.04.1 is widely deployed.

PPAs are well supported with our existing tooling (saltstack, etc) and
allow granular access to only the desired package (LXD) and its
dependencies. Snap packages are not an option for my company at this time.

If I understand correctly, enabling the backports repository on LTS
production systems to obtain new LXD versions may require extensive version
pinning to keep existing installed packages at their current versions.

Given that LXD is a major project of Canonical, continuing to provide an
existing official PPA is helpful to users, consistent with other projects
publishing debian packages, and worth the effort to continue maintenance
going forward.

Thanks for considering the request.
Jeff


[1] Deprecation notice:

LXD PPAs to go away by end of year

We are deprecating all LXD PPAs at the end of 2017.

Existing users should move to the LXD snap as the preferred way to get the
latest LXD feature release on older Ubuntu releases.

You can do so by first installing snapd on your system if it's not there
already. Once snapd is installed, installing the LXD snap and migrating your
existing data can be done with:

snap install lxd && lxd.migrate

Alternatively, we do still provide a .deb version of LXD for older Ubuntu
releases through the official -backports archive pocket.

Those packages are identical to what's available through our PPAs but
benefit
from additional testing on our part. To switch over to those backport
packages,
use:

apt install -t <release>-backports lxd lxd-client

Replacing "<release>" with the codename of your Ubuntu release (e.g.
xenial).
Thomas Ward
2017-12-27 17:04:05 UTC
Permalink
Uhm... I think you're confused here Jeff.  Allow me to explain.

In Standard Ubuntu releases, Backports is *actually enabled* but set at
a lower pin priority by default.  That is, you can have backports
enabled and then only *selectively* install from Backports.  This is a
standard 16.04 system and its corresponding Backports priority data from
`apt-cache priority`:

 100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=i386
 100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=amd64
 100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main i386 Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=i386
 100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=amd64

This indicates it's a lower priority than the updates or other
repositories, such as the standard xenial-updates, which is shown here
below:

 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiverse,b=i386
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiverse,b=amd64
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=universe,b=i386
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=universe,b=amd64
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restricted,b=i386
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restricted,b=amd64
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,b=i386
 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,b=amd64


The priority of 100 is lower than the priority of 500; ultimately, the
version pinning *by default* sticks backports as an optional,
you-must-specify-to-install-from-backports option.  Therefore, you do
***not*** need extensive version pinning in Ubuntu releases to use
backports alongside standard system packages, as the system by-default
deprioritizes Backports unless you've installed something specifically
from Backports.  (PPAs actually operate completely differently, and get
the 500 priority which can actually result in clobbering of data between
repos)

Ultimately, this is ***not*** going to need extensive version pinning. 
Trust me on this, as someone who's done this myself on four separate
environments and actively uses LXD to run multiple production-level
services actively via the four boxes - backports being enabled don't
impact things like you think it does.

(I had this same misconception in the 14.04 era, but after talking with
the release team and other server team members, this is no longer the case).


Thomas
Ubuntu Server Team Member
LP: ~teward
When updating LXD 2.20 on Ubuntu 16.04, I noticed the PPA deprecation
notice, included below [1].
I'd like to respectfully ask that the PPA not be deprecated and
continue to see new package versions. Or at the very least, see
deprecation deferred until after the next LTS 18.04.1 is widely deployed.
PPAs are well supported with our existing tooling (saltstack, etc) and
allow granular access to only the desired package (LXD) and its
dependencies. Snap packages are not an option for my company at this time.
If I understand correctly, enabling the backports repository on LTS
production systems to obtain new LXD versions may require extensive
version pinning to keep existing installed packages at their current
versions.
Given that LXD is a major project of Canonical, continuing to provide
an existing official PPA is helpful to users, consistent with other
projects publishing debian packages, and worth the effort to continue
maintenance going forward.
Thanks for considering the request.
Jeff
LXD PPAs to go away by end of year
We are deprecating all LXD PPAs at the end of 2017.
Existing users should move to the LXD snap as the preferred way to get the
latest LXD feature release on older Ubuntu releases.
You can do so by first installing snapd on your system if it's not there
already. Once snapd is installed, installing the LXD snap and
migrating your
snap install lxd && lxd.migrate
Alternatively, we do still provide a .deb version of LXD for older Ubuntu
releases through the official -backports archive pocket.
Those packages are identical to what's available through our PPAs but
benefit
from additional testing on our part. To switch over to those backport
packages,
apt install -t <release>-backports lxd lxd-client
Replacing "<release>" with the codename of your Ubuntu release (e.g.
xenial).
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
Jeff Kowalczyk
2017-12-27 17:41:24 UTC
Permalink
Thank you, Thomas. Your explanation clears things up entirely, and I
learned several things about apt in the process. Concerns about PPA
deprecation withdrawn.

Jeff
Uhm... I think you're confused here Jeff. Allow me to explain.
In Standard Ubuntu releases, Backports is *actually enabled* but set at a
lower pin priority by default. That is, you can have backports enabled and
then only *selectively* install from Backports. This is a standard 16.04
system and its corresponding Backports priority data from `apt-cache
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe i386
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=
universe,b=i386
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=
universe,b=amd64
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main i386
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=
main,b=i386
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=
main,b=amd64
This indicates it's a lower priority than the updates or other
repositories, such as the standard xenial-updates, which is shown here
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse i386
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
multiverse,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
multiverse,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe i386
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
universe,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
universe,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted i386
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
restricted,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
restricted,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
main,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=
main,b=amd64
The priority of 100 is lower than the priority of 500; ultimately, the
version pinning *by default* sticks backports as an optional,
you-must-specify-to-install-from-backports option. Therefore, you do
***not*** need extensive version pinning in Ubuntu releases to use
backports alongside standard system packages, as the system by-default
deprioritizes Backports unless you've installed something specifically from
Backports. (PPAs actually operate completely differently, and get the 500
priority which can actually result in clobbering of data between repos)
Ultimately, this is ***not*** going to need extensive version pinning.
Trust me on this, as someone who's done this myself on four separate
environments and actively uses LXD to run multiple production-level
services actively via the four boxes - backports being enabled don't impact
things like you think it does.
(I had this same misconception in the 14.04 era, but after talking with
the release team and other server team members, this is no longer the case).
Thomas
Ubuntu Server Team Member
LP: ~teward
When updating LXD 2.20 on Ubuntu 16.04, I noticed the PPA deprecation
notice, included below [1].
I'd like to respectfully ask that the PPA not be deprecated and continue
to see new package versions. Or at the very least, see deprecation deferred
until after the next LTS 18.04.1 is widely deployed.
PPAs are well supported with our existing tooling (saltstack, etc) and
allow granular access to only the desired package (LXD) and its
dependencies. Snap packages are not an option for my company at this time.
If I understand correctly, enabling the backports repository on LTS
production systems to obtain new LXD versions may require extensive version
pinning to keep existing installed packages at their current versions.
Given that LXD is a major project of Canonical, continuing to provide an
existing official PPA is helpful to users, consistent with other projects
publishing debian packages, and worth the effort to continue maintenance
going forward.
Thanks for considering the request.
Jeff
LXD PPAs to go away by end of year
We are deprecating all LXD PPAs at the end of 2017.
Existing users should move to the LXD snap as the preferred way to get the
latest LXD feature release on older Ubuntu releases.
You can do so by first installing snapd on your system if it's not there
already. Once snapd is installed, installing the LXD snap and migrating your
snap install lxd && lxd.migrate
Alternatively, we do still provide a .deb version of LXD for older Ubuntu
releases through the official -backports archive pocket.
Those packages are identical to what's available through our PPAs but
benefit
from additional testing on our part. To switch over to those backport
packages,
apt install -t <release>-backports lxd lxd-client
Replacing "<release>" with the codename of your Ubuntu release (e.g.
xenial).
_______________________________________________
Thomas Ward
2017-12-27 17:50:46 UTC
Permalink
Glad to hear it cleared things up!

Just to clarify my post, though, for others, the 'standard' system I was
referring to was my 16.04 Desktop installation.

Just to get the 'bog standard default' policy sets, I spun up a pristine
16.04 image in LXD, and pulled the `apt-cache policy` from it:

***@test-xenial-image:~# apt-cache policy | grep backports
 100 http://archive.ubuntu.com/ubuntu xenial-backports/universe amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=amd64
 100 http://archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=amd64

As is seen here, it too has backports enabled, and has the lower pin
priority.  This should be *standard* therefore, though I don't have a
pure Ubuntu server here just now to reconfirm.  However, default pins
seem to place it at lower priority, and therefore a purely optional
'must be specified as installation source' option during installtion
steps.  (It's how I moved off the PPAs and onto the Backports without
issue for my LXD 'hypervisor' servers, and my own laptop for LXD as well).


Thomas
Post by Jeff Kowalczyk
Thank you, Thomas. Your explanation clears things up entirely, and I
learned several things about apt in the process. Concerns about PPA
deprecation withdrawn.
Jeff
Uhm... I think you're confused here Jeff.  Allow me to explain.
In Standard Ubuntu releases, Backports is *actually enabled* but
set at a lower pin priority by default.  That is, you can have
backports enabled and then only *selectively* install from
Backports.  This is a standard 16.04 system and its corresponding
 100 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-backports/universe
i386 Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=i386
 100 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-backports/universe
amd64 Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=amd64
 100 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-backports/main i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=i386
 100 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-backports/main amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=amd64
This indicates it's a lower priority than the updates or other
repositories, such as the standard xenial-updates, which is shown
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/multiverse
i386 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiverse,b=i386
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/multiverse
amd64 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiverse,b=amd64
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/universe i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=universe,b=i386
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/universe
amd64 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=universe,b=amd64
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/restricted
i386 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restricted,b=i386
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/restricted
amd64 Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restricted,b=amd64
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/main i386
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,b=i386
 500 http://us.archive.ubuntu.com/ubuntu
<http://us.archive.ubuntu.com/ubuntu> xenial-updates/main amd64
Packages
     release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,b=amd64
The priority of 100 is lower than the priority of 500; ultimately,
the version pinning *by default* sticks backports as an optional,
you-must-specify-to-install-from-backports option.  Therefore, you
do ***not*** need extensive version pinning in Ubuntu releases to
use backports alongside standard system packages, as the system
by-default deprioritizes Backports unless you've installed
something specifically from Backports.  (PPAs actually operate
completely differently, and get the 500 priority which can
actually result in clobbering of data between repos)
Ultimately, this is ***not*** going to need extensive version
pinning.  Trust me on this, as someone who's done this myself on
four separate environments and actively uses LXD to run multiple
production-level services actively via the four boxes - backports
being enabled don't impact things like you think it does.
(I had this same misconception in the 14.04 era, but after talking
with the release team and other server team members, this is no
longer the case).
Thomas
Ubuntu Server Team Member
LP: ~teward
When updating LXD 2.20 on Ubuntu 16.04, I noticed the PPA
deprecation notice, included below [1].
I'd like to respectfully ask that the PPA not be deprecated and
continue to see new package versions. Or at the very least, see
deprecation deferred until after the next LTS 18.04.1 is widely deployed.
PPAs are well supported with our existing tooling (saltstack,
etc) and allow granular access to only the desired package (LXD)
and its dependencies. Snap packages are not an option for my
company at this time.
If I understand correctly, enabling the backports repository on
LTS production systems to obtain new LXD versions may require
extensive version pinning to keep existing installed packages at
their current versions.
Given that LXD is a major project of Canonical, continuing to
provide an existing official PPA is helpful to users, consistent
with other projects publishing debian packages, and worth the
effort to continue maintenance going forward.
Thanks for considering the request.
Jeff
LXD PPAs to go away by end of year
We are deprecating all LXD PPAs at the end of 2017.
Existing users should move to the LXD snap as the preferred way to get the
latest LXD feature release on older Ubuntu releases.
You can do so by first installing snapd on your system if it's not there
already. Once snapd is installed, installing the LXD snap and migrating your
snap install lxd && lxd.migrate
Alternatively, we do still provide a .deb version of LXD for older Ubuntu
releases through the official -backports archive pocket.
Those packages are identical to what's available through our PPAs
but benefit
from additional testing on our part. To switch over to those
backport packages,
apt install -t <release>-backports lxd lxd-client
Replacing "<release>" with the codename of your Ubuntu release
(e.g. xenial).
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
<http://lists.linuxcontainers.org/listinfo/lxc-users>
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
laurent ducos
2017-12-28 08:32:03 UTC
Permalink
Hello
I have two questions.

* The exact date of end of ppa is not specified. What is the expected day?
* Actualy my version of lxd is 2.16..I will update it on January 5th. If
the support of the ppa is finished I would only have to delete the entries
in "/etc/apt/sources.list.d/ubuntu-lxc-ubuntu-lxd-stable-xenial.list" then
"apt update" and "apt install -t xenial-backports lxd lxd-client" Nothing
else to do ?
Post by Thomas Ward
Glad to hear it cleared things up!
Just to clarify my post, though, for others, the 'standard' system I was
referring to was my 16.04 Desktop installation.
Just to get the 'bog standard default' policy sets, I spun up a pristine
100 http://archive.ubuntu.com/ubuntu xenial-backports/universe amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=
universe,b=amd64
100 http://archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=
main,b=amd64
As is seen here, it too has backports enabled, and has the lower pin
priority. This should be *standard* therefore, though I don't have a pure
Ubuntu server here just now to reconfirm. However, default pins seem to
place it at lower priority, and therefore a purely optional 'must be
specified as installation source' option during installtion steps. (It's
how I moved off the PPAs and onto the Backports without issue for my LXD
'hypervisor' servers, and my own laptop for LXD as well).
Thomas
Thank you, Thomas. Your explanation clears things up entirely, and I
learned several things about apt in the process. Concerns about PPA
deprecation withdrawn.
Jeff
Uhm... I think you're confused here Jeff. Allow me to explain.
In Standard Ubuntu releases, Backports is *actually enabled* but set at a
lower pin priority by default. That is, you can have backports enabled and
then only *selectively* install from Backports. This is a standard 16.04
system and its corresponding Backports priority data from `apt-cache
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe i386
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=univ
erse,b=i386
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=univ
erse,b=amd64
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main i386
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main
,b=i386
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main
,b=amd64
This indicates it's a lower priority than the updates or other
repositories, such as the standard xenial-updates, which is shown here
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse i386
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiv
erse,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiv
erse,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe i386
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=univer
se,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=univer
se,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted i386
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restri
cted,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restri
cted,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,
b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
release v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,
b=amd64
The priority of 100 is lower than the priority of 500; ultimately, the
version pinning *by default* sticks backports as an optional,
you-must-specify-to-install-from-backports option. Therefore, you do
***not*** need extensive version pinning in Ubuntu releases to use
backports alongside standard system packages, as the system by-default
deprioritizes Backports unless you've installed something specifically from
Backports. (PPAs actually operate completely differently, and get the 500
priority which can actually result in clobbering of data between repos)
Ultimately, this is ***not*** going to need extensive version pinning.
Trust me on this, as someone who's done this myself on four separate
environments and actively uses LXD to run multiple production-level
services actively via the four boxes - backports being enabled don't impact
things like you think it does.
(I had this same misconception in the 14.04 era, but after talking with
the release team and other server team members, this is no longer the case).
Thomas
Ubuntu Server Team Member
LP: ~teward
When updating LXD 2.20 on Ubuntu 16.04, I noticed the PPA deprecation
notice, included below [1].
I'd like to respectfully ask that the PPA not be deprecated and continue
to see new package versions. Or at the very least, see deprecation deferred
until after the next LTS 18.04.1 is widely deployed.
PPAs are well supported with our existing tooling (saltstack, etc) and
allow granular access to only the desired package (LXD) and its
dependencies. Snap packages are not an option for my company at this time.
If I understand correctly, enabling the backports repository on LTS
production systems to obtain new LXD versions may require extensive version
pinning to keep existing installed packages at their current versions.
Given that LXD is a major project of Canonical, continuing to provide an
existing official PPA is helpful to users, consistent with other projects
publishing debian packages, and worth the effort to continue maintenance
going forward.
Thanks for considering the request.
Jeff
LXD PPAs to go away by end of year
We are deprecating all LXD PPAs at the end of 2017.
Existing users should move to the LXD snap as the preferred way to get the
latest LXD feature release on older Ubuntu releases.
You can do so by first installing snapd on your system if it's not there
already. Once snapd is installed, installing the LXD snap and migrating your
snap install lxd && lxd.migrate
Alternatively, we do still provide a .deb version of LXD for older Ubuntu
releases through the official -backports archive pocket.
Those packages are identical to what's available through our PPAs but
benefit
from additional testing on our part. To switch over to those backport
packages,
apt install -t <release>-backports lxd lxd-client
Replacing "<release>" with the codename of your Ubuntu release (e.g.
xenial).
_______________________________________________
_______________________________________________
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
Jeffrey Lane
2017-12-28 14:28:38 UTC
Permalink
Post by laurent ducos
Hello
I have two questions.
* The exact date of end of ppa is not specified. What is the expected day?
* Actualy my version of lxd is 2.16..I will update it on January 5th. If
the support of the ppa is finished I would only have to delete the entries
in "/etc/apt/sources.list.d/ubuntu-lxc-ubuntu-lxd-stable-xenial.list" then
"apt update" and "apt install -t xenial-backports lxd lxd-client" Nothing
else to do ?
Or you could do as they suggest in the deprecation and begin using the
snapped version of LXD going forward. That will get you the latest LXD with
each snap update and you won’t have to ever worry about apt pinning or
which PPA to use as the snaps are self-contained.
Post by laurent ducos
Post by Thomas Ward
Glad to hear it cleared things up!
Just to clarify my post, though, for others, the 'standard' system I was
referring to was my 16.04 Desktop installation.
Just to get the 'bog standard default' policy sets, I spun up a pristine
100 http://archive.ubuntu.com/ubuntu xenial-backports/universe amd64
Packages
release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=amd64
100 http://archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages
release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=amd64
As is seen here, it too has backports enabled, and has the lower pin
priority. This should be *standard* therefore, though I don't have a pure
Ubuntu server here just now to reconfirm. However, default pins seem to
place it at lower priority, and therefore a purely optional 'must be
specified as installation source' option during installtion steps. (It's
how I moved off the PPAs and onto the Backports without issue for my LXD
'hypervisor' servers, and my own laptop for LXD as well).
Thomas
Thank you, Thomas. Your explanation clears things up entirely, and I
learned several things about apt in the process. Concerns about PPA
deprecation withdrawn.
Jeff
Uhm... I think you're confused here Jeff. Allow me to explain.
In Standard Ubuntu releases, Backports is *actually enabled* but set at
a lower pin priority by default. That is, you can have backports enabled
and then only *selectively* install from Backports. This is a standard
16.04 system and its corresponding Backports priority data from `apt-cache
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe i386
Packages
release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=i386
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/universe
amd64 Packages
release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=amd64
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main i386
Packages
release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=i386
100 http://us.archive.ubuntu.com/ubuntu xenial-backports/main amd64
Packages
release
v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=main,b=amd64
This indicates it's a lower priority than the updates or other
repositories, such as the standard xenial-updates, which is shown here
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse i386
Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiverse,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/multiverse
amd64 Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=multiverse,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe i386
Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=universe,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/universe amd64
Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=universe,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted i386
Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restricted,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/restricted
amd64 Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=restricted,b=amd64
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,b=i386
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
release
v=16.04,o=Ubuntu,a=xenial-updates,n=xenial,l=Ubuntu,c=main,b=amd64
The priority of 100 is lower than the priority of 500; ultimately, the
version pinning *by default* sticks backports as an optional,
you-must-specify-to-install-from-backports option. Therefore, you do
***not*** need extensive version pinning in Ubuntu releases to use
backports alongside standard system packages, as the system by-default
deprioritizes Backports unless you've installed something specifically from
Backports. (PPAs actually operate completely differently, and get the 500
priority which can actually result in clobbering of data between repos)
Ultimately, this is ***not*** going to need extensive version pinning.
Trust me on this, as someone who's done this myself on four separate
environments and actively uses LXD to run multiple production-level
services actively via the four boxes - backports being enabled don't impact
things like you think it does.
(I had this same misconception in the 14.04 era, but after talking with
the release team and other server team members, this is no longer the case).
Thomas
Ubuntu Server Team Member
LP: ~teward
When updating LXD 2.20 on Ubuntu 16.04, I noticed the PPA deprecation
notice, included below [1].
I'd like to respectfully ask that the PPA not be deprecated and continue
to see new package versions. Or at the very least, see deprecation deferred
until after the next LTS 18.04.1 is widely deployed.
PPAs are well supported with our existing tooling (saltstack, etc) and
allow granular access to only the desired package (LXD) and its
dependencies. Snap packages are not an option for my company at this time.
If I understand correctly, enabling the backports repository on LTS
production systems to obtain new LXD versions may require extensive version
pinning to keep existing installed packages at their current versions.
Given that LXD is a major project of Canonical, continuing to provide an
existing official PPA is helpful to users, consistent with other projects
publishing debian packages, and worth the effort to continue maintenance
going forward.
Thanks for considering the request.
Jeff
LXD PPAs to go away by end of year
We are deprecating all LXD PPAs at the end of 2017.
Existing users should move to the LXD snap as the preferred way to get the
latest LXD feature release on older Ubuntu releases.
You can do so by first installing snapd on your system if it's not there
already. Once snapd is installed, installing the LXD snap and migrating your
snap install lxd && lxd.migrate
Alternatively, we do still provide a .deb version of LXD for older Ubuntu
releases through the official -backports archive pocket.
Those packages are identical to what's available through our PPAs but
benefit
from additional testing on our part. To switch over to those backport
packages,
apt install -t <release>-backports lxd lxd-client
Replacing "<release>" with the codename of your Ubuntu release (e.g.
xenial).
_______________________________________________
_______________________________________________
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
--
Sent from my iPhone so please forgive any typos, top posting and such.
Continue reading on narkive:
Loading...