[lxc-users] LXD Official PPA deprecation

laurent ducos laurentducos at gmail.com
Thu Dec 28 08:32:03 UTC 2017 

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 ?

2017-12-27 18:50 GMT+01:00 Thomas Ward <teward at ubuntu.com>:

> 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:
>
> root at 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
>
>
> On 12/27/2017 12:41 PM, Jeff Kowalczyk wrote:
>
> 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
>
> On Wed, Dec 27, 2017 at 9:04 AM, Thomas Ward <teward at ubuntu.com> wrote:
>
>> 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=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
>> 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=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
>>
>> On 12/27/2017 11:57 AM, Jeff Kowalczyk wrote:
>>
>> 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).
>>
>>
>>
>> _______________________________________________
>> lxc-users mailing listlxc-users at lists.linuxcontainers.orghttp://lists.linuxcontainers.org/listinfo/lxc-users
>>
>>
>>
>
>
> _______________________________________________
> lxc-users mailing listlxc-users at lists.linuxcontainers.orghttp://lists.linuxcontainers.org/listinfo/lxc-users
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20171228/5977e178/attachment-0001.html>

More information about the lxc-users mailing list