0

I am trying to install specific package versions to maintain my production server in sync with my staging system. When I specify the version I get this:

root@ip-172-19-69-40:~/installs# apt install libc6=2.31-0ubuntu9.15
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Version '2.31-0ubuntu9.15' for 'libc6' was not found

There is a similar question here: Unable to install specific package version with apt-get Which states:

"Older Packages are pruned from ubuntu repo's and not kept around."

Which would make sense, except I installed this version about 4 weeks ago on my staging server. I don't understand how this version was considered old enough to purge as of 4 weeks ago.

Can someone help me understand how I would go about getting that version installed?

Beyond that some additional info:

This is my staging system:

root@ip-172-20-57-64:~# apt policy libc6
libc6:
  Installed: 2.31-0ubuntu9.15
  Candidate: 2.31-0ubuntu9.16
  Version table:
     2.31-0ubuntu9.16 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
 *** 2.31-0ubuntu9.15 100
        100 /var/lib/dpkg/status
     2.31-0ubuntu9 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu focal/main amd64 Packages

And here is a production-clone:

root@ip-172-19-69-40:~/installs# apt policy libc6
libc6:
  Installed: 2.31-0ubuntu9.7
  Candidate: 2.31-0ubuntu9.16
  Version table:
     2.31-0ubuntu9.16 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
 *** 2.31-0ubuntu9.7 100
        100 /var/lib/dpkg/status
     2.31-0ubuntu9 500
        500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

I installed 2.31-0ubuntu9.15 around 4 weeks ago - it' gone already???

1 Answers1

0

A Bit of an Explanation

Before we get to the meat of the OP's problem, I need to layout a bit of a foundation for us:

  1. What is a Compiler Toolchain? - Since this is Ubuntu, we'll start with the Ubuntu documentation - Toolchain. The four packages discussed there can also include extras as seen in the Gentoo Toolchain maintainers Page, but at a bare minimum must include everything in Section 5, no matter the distribution.
  2. What is libc6? - Quoting Wikipedia:

Fork and variant

In 1994, the developers of the Linux kernel forked glibc. Their fork, "Linux libc", was maintained separately until around 1998. Because the copyright attribution was insufficient, changes could not be merged back to the GNU Libc. When the FSF released glibc 2.0 in January 1997, the kernel developers discontinued Linux libc due to glibc 2.0's superior compliance with POSIX standards. glibc 2.0 also had better internationalisation and more in-depth translation, IPv6 capability, 64-bit data access, facilities for multithreaded applications, future version compatibility, and the code was more portable. The last-used version of Linux libc used the internal name (soname) libc.so.5. Following on from this, glibc 2.x on Linux uses the soname libc.so.6

  1. Why is GLibC so important? -

The GNU C Library is a wrapper around the system calls of the Linux kernel.

See photo here.

How all This Fits Together

In a shortened version of my answer here, all packages on any distribution go through 3 phases:

  1. Build/Compile
  2. Packaging by the Maintainer or Distribution
  3. Uploading to the desired repository

All packages for every distribution known must go through these three phases. Yes some distributions borrow other distributions as a starting point, like so:

  1. Linux Mint was forked from Ubuutu, but
  2. Ubuntu was forked from Debian.

See photo here. The above is the reason why shortly after there is a new release of Ubuntu there is a release of Mint. If Mint chose not to follow Ubuntu's release schedule, Mint would now be in charge of managing the last repository they borrowed from plus adding all the items that make Mint Mint. Knowing that they need to still follow the three phases above, Mint wisely chose to let Ubuntu do all the heavy lifting so that Mint only has to adhere to the 3 phases for packages that make up Mint.

Now onto the Meat

The OP has correctly chosen to version lock whatever project he is working on, which I commend him for, but he has chosen the wrong approach out of these 3:

  1. Do Nothing
  2. Let APT do all the Work - He's chosen this incorrectly
  3. Create a Local Repository - This must be the correct approach as the OP must also follow the same 3 phases described above. To do this he has two options
    • Make the Production Server match the Development Server
    • Make the Development Server match the Production Server

If he is building custom code he must use the compiler on the production server, so we need a bit of research:

  1. Using Section 5 again as a guide, do the following:
    • Use apt to determine the versions of all the packages from the Section 5 list that are installed, on both servers.
    • Take the greater of the 2 versions and store that in your local repository, along with whatever other packages you need.
      • In theory, any lesser versioned code should work with the greater version because of backwards compatibility, unless there was an ABI update between versions, but that only occurs very rarely with toolchain items.
  2. For simplicity sake, all of the items that are included in the toolchain are available in the build-essential package. The only time this package will contain different toolchain items is between distribution versions, i.e. 21.04 vs 22.04.
  3. Allow both the Production and Development Servers access to the local repository.
eyoung100
  • 975