Gfilui

tl;dr: Does Ubuntu LTS update libraries to versions where API elements may be changed/removed?

Due to Debian stable's lack of patching their kernels to support new hardware, I've run into problems where new laptops at my organization are too new to run Debian stable. I hired a Debian contractor to create an installation CD with a backported kernel, but one week later and he hasn't been able to produce it.

Now I'm forced to consider migrating the company to Ubuntu LTS. But I lose sleep over the following nightmare:

• I arrive at work early one morning a few days before a big demo for our customer.


• I've got some time so I apt upgrade.


• 
  After hitting Y I notice that qt5-default has incremented from 5.9.5 to 5.10.0.


• I compile our project only to find that the API has changed.


• Our team needs about 2 weeks to re-write the code to adapt.


• We miss the demo and lose the bid.


• The company goes bankrupt and we all lose our jobs.

With Debian, I don't have this worry because it simply doesn't update. We get security patches only. The heartbreaking trade-off is that new hardware isn't supported. Since I don't have the kind of pull with the OEM to order only laptops manufactured before Debian stable's release I need another solution.

Ubuntu LTS claims that they only perform "point releases". When I look at the Kernel history of 16.04 to figure out what that means, I see that they did update the kernel from 4.4 to 4.15. This tells me that Ubuntu may not be willing to increment the major revision, but they are willing to increment the minor revision.

I'm fine with an update from libboost from 1.67.0 to 1.67.1, but I'm terrified of an update to 1.68.0.

Can I be confident that Ubuntu LTS will not upgrade packages which are not reverse compatible?

If I cannot be confident in Ubuntu's stability, then the following are possible work-arounds, though suggestions are welcome:

1. 
   apt-mark hold <package> will prevent upgrades for specific packages, However:
   
   
   1. Manually managing dependencies will be time-consuming
   
   
   2. I need to control this company-wide.
   
   


2. Development could be done in a chroot environment running debian stable, isolating the development environment from desktop environment.

Updating Ubuntu LTS does not upgrade the kernel version. Only security patches are being applied.

Current LTS release is bionic.

Ubuntu 18.4.1 (26.4.2018)

Automatic kernel updates in LTS release are enabled by Hardware Enablement Stack only.

Ubuntu Kernel Release Shedule

Here you can see that no kernel upgrades in LTS were done unless HWE enabled.

Ubuntu LTS Kernel Support Shedule

Here you can see that only security patches have been implemented.

Does Ubuntu LTS update libraries to versions where API elements may be changed/removed?
The answer is no.

Can I be confident that Ubuntu LTS will not upgrade packages which are not reverse compatible?
The answer is yes you can.

The same applies to Debian stable.

Current stable release is stretch.
Debian 9.5 (released 14.7.2018, supported until 2022)

Development on linux

Best practice for software development in corporate environment is to run a virtual machine, so you can easily protect your work with snapshots.

Example
Qubes OS is a security-oriented operating system, which allows you to run virtual machines (and templates, including debian) using XEN hypervisor (instead of KVM virtualization)

If you are using Qt and need to prevent it from updating, try setUpdatesEnabled(false); and to enable updates setUpdatesEnabled(true);

Ubuntu Kernel numbering is not the same as Linux

Search in Ask Ubuntu using 4.13.0-26 and you'll find 101 questions and answers from January 2018. Linux Kernel versions being released at that time were for the LTS kernel 4.14 chain.

Looking at Ubuntu Mainline Kernel downloads we see 4.14.11 through 4.14.17 (seven kernel updates) were released in January 2018 by the Linux Kernel Team. We also see the Release Candidate kernel for the January 2018 was 4.15.rc6 through 4.15.rc9 (four kernel updates).

In January 2018 major kernel revisions were made by the Linux Kernel Team for the Spectre and Meltdown Predictive Branching theoretical memory leak. In turn the Ubuntu Kernel team quickly ported the code to Ubuntu Kernel 4.13.0-xx chain.

Tracking ABI/API changes

From the ABI Labratory we can see the last changes were on June 4, 5 and 6th, 2018:

We can see the Linux Kernel numbers revised in June 2018 were:

• 
  4.14.48, 4.9.107 and 4.4.136 all 6 year LTS kernels

The corresponding Ubuntu Kernel version numbers were probably:

• 
  4.13.0-43 headers failed to install: Linux kernel header files to match the current kernel
  


• 
  4.15.0-23 apt removal script broken
  

We need to upgrade Linux Kernels when new hardware support or bug fixes to existing hardware are released. When an ABI/API change is involved the Ubuntu kernel may or may not work. Even if an ABI/API change doesn't take place the Ubuntu Kernel may still break for some people for other reasons.

Finding correlation between new Linux Kernel version numbering and Ubuntu Kernel version numbering is extremely difficult for outsiders. Take the most recent newsletter from the Ubuntu Kernel Team June 6th, 2017 newsletter which is one year prior to the ABI/API changes above:

Kernel Versions
====================================================================
 precise 3.2.0-126.169
 trusty 3.13.0-119.166
 vivid 3.19.0-84.92
 xenial 4.4.0-78.99
 yakkety 4.8.0-53.56

linux-lts-trusty 3.13.0-117.164~precise1
 linux-lts-vivid 3.19.0-80.88~14.04.1
linux-lts-xenial 4.4.0-78.99~14.04.1

We see the corresponding Linux Kernel version numbers for that time period (June 7, 2017) were: 3.2.89, 3.10.105, 3.16.44, 3.18.56, 4.1.40, 4.4.71, 4.9.31, 4.11.4 and 4.12-rc4.

Cloning and Function testing

Rather than ad-hoc sudo apt upgrade on sleepy Monday mornings you could consider automated cloning, upgrade and function testing:

1. A job runs at midnight to clone your 16.04 or 18.04 to a test partition: Bash script to clone Ubuntu to new partition for testing 18.04 LTS upgrade
   


2. After cloning a small cron reboot script is created to run sudo apt upgrade and run your test function.


3. After cloning grub reboot is called to the clone version: Grub: reboot to specific kernel
   


4. When the clone is rebooted the cron reboot script runs for unattended upgrade and unit testing.


5. Your unit testing should compare all library version numbers to known numbers and email you if version numbers have updated to untested numbers.


6. Your unit testing would call all known functions passing test parameters and comparing returned values to expected results. Any discrepancies would be emailed to you.


7. Upon completion your unit testing script would email you final results, set grub to reboot to live environment and then shutdown.