Ubuntu Wiki

• Launchpad Entry: desktop-q-xorg-lts-updates desktop-r-xorg-lts-updates

• Created: 2011-11-16

• Contributors: BryceHarrington, ChrisHalseRogers, SteveLangasekm, MaartenLankhorst

• Packages affected: Much of the X stack, primarily drivers and xorg-server

• UDS discussion: http://summit.ubuntu.com/uds-p/meeting/19876/foundations-p-xorg-lts-updates/

Summary

We will be updating the X stack (server-side only) for LTS point releases starting with 12.04.2 and continuing for three releases. This blueprint describes the technical steps needed for conducting these updates.

Release Note

Canonical has announced a new 5-year LTS support policy for the Ubuntu Desktop which will provide updates to X, drivers, and necessary plumbing layer components to provide support for newer hardware in the LTS.

Rationale

Historically once an LTS is completed we've not updated the X components beyond the versions included in the release. However, this means that the LTS will not pick up new hardware support over time, and so the value of the LTS for desktop usage quickly diminishes.

Upstream sometimes produces stable minor updates for X.org, but we don't pull those into the LTS. Also, these minor updates tend to be bug fixes, not hardware support so much. So even if we did pull in the stable updates, it wouldn't address the problem.

Meanwhile, we do tend to update the kernel on LTS releases to new major versions. This blueprint focuses on the idea of doing the same with the X.org components.

Another benefit of doing point releases on the LTS is that it allows us to be more conservative in the release itself with the versions we select.

Design

We will be backporting the X stack from future non-LTS releases to the LTS release point releases, up to the next LTS.

The point releases occur at 6-month intervals starting 3-months after release. Since there won't be a stable non-LTS release at the 3-month mark, this means we will shoot for the following schedule:

The new stacks will be introduced alongside the stock 12.04 stack and will co-exist with them. All of the packages will be renamed to not conflict with the packages in the stock 12.04 stack. We will utilize mesa's alternatives system to install the updated GL libraries and enable them.

This way, users who install 12.04.0 and have it working on their hardware will *not* be automatically upgraded to the new X stack (unless they specifically choose to), while those who do fresh installs with the point release ISOs will install the new stack preferentially.

Once you've installed from the 12.04.3 media (with the R stack), you can't upgrade to Q without getting into weird corner cases with backported packages on the system, or regress hardware support. See the table above for the upgrade paths. Update-manager will need to be taught to clean up the newer stack on upgrade to Q; hopefully that won't open a huge can of worms.

The non-LTS update X stacks (Q, R, and S) will have shorter security support lifetimes: 15 months following the point release. Once security support for the X stack for a given point release, we will require upgrading to the next supported point release. So, after updating to 12.04.2 in January 2013, they would be prompted to upgrade to 12.04.3 in July. If they choose not to do so they can remain on 12.04.2 until April 2014 at which point they're required to update to 12.04.3 (and directly given the option to upgrade to 12.04.4 if they'd like). 12.04.4 is based on the T-series, which is another LTS release and users can choose to remain there until end of life for 12.04; even if there are further point releases we will not be updating the X stack further after that point.

Only the server-side components of the X stack will be upgraded, not libX11 or any other client-side code. This is to ensure no changes to any client applications are required. Obviously this may introduce some skew between client-side and server-side, but it's been our experience that the client-side portions of X tend to be relatively stable and free of interdependencies with the server components. Still, we will need to keep an eye on this and especially do full testing on the client side in case there are any issues to be found.

There have been cases where X driver vendors drop support for older chipsets. Thus it is possible that a system installed with 12.04 will not work with the 12.04.[2,3,4] stack. Since the 12.04.0 X stack will always be available, in this case we would recommend they stay on that stack. Where this might become a problem would be if 12.04.2 worked on their hardware but 12.04.3 or 12.04.4 did not; in these cases the user might be required to upgrade to a version that will simply be broken for their hardware. Ideally the upgrader would be made aware of these situations (to the extent that we're aware of the loss of support) and not offer the upgrade on affected hardware; in practice this may be a fairly rare corner case.

Implementation

The X.org packages will be renamed following the kernel convention ('linux-lts-natty' c.f. bug #806586), to enable them to co-exist in the same archive. Thus, the X package names will have 'lts-VERSION' appended to them:

   mesa-lts-quixotic
   xserver-xorg-video-intel-lts-quantal
   xserver-xorg-video-intel-dbg-lts-quantal
   xorg-server-lts-quantal
   xserver-xorg-core-dbg-lts-quantal
   xserver-common-lts-quantal
   etc.

'xserver-xorg-lts-quantal' will be used for switching to the lst-quantal stack. Binary drivers will not be renamed, instead they're required to work on both stacks by depending on multiple xorg video abi's. Newer versions of those drivers might need to be sru'd to precise. A fix for bug 1062503 is needed before a upgrade should be atttempted.

Testing

Switching stacks is mostly straightforward, but certain packages might end up being removed. Since switching X stacks is a scary operation, tests with multiarch needs to be performed to make sure that the default 'apt-get install xserver-xorg-lts-quantal' always does something sane, and that removing all *-lts-quantal* will revert back to the original x server safely.

Similar testing should also be done with fglrx and nvidia drivers installed. This should potentially be done on arm as well, with fallback to llvmpipe if the EGL drivers start failing.

At no point should apt-get abort midway through, since this can leave the system in a very skewed state from which it is hard to recover.

Questions