End of a Legacy : A Proposal to End-of-Life Our Generic Linux Tar Packages

Matt Lord


TL;DR: We are planning to end distribution of the Legacy Generic Linux x64 Tar packages starting with MongoDB 4.2. We are seeking feedback from the community before a final decision is made.

Computing History

In a bygone era magnetic tape was a primary storage medium and the simple tar archive (tar) was the method and medium used to create bundles of files — A.K.A. a "tarball" — and archive them on the tape.

The fathers of Unix — Dennis Ritchie and Ken Thompson — at Bell Labs circa 1970
The fathers of Unix — Dennis Ritchie and Ken Thompson — at Bell Labs circa 1970

These tar files also became a convenient and common way to distribute software — which is precisely what we did at MongoDB for Unix-like systems early in our own history.

Modern Computing

While this was a wonderful time in the history of computing, a lot has changed. All popular operating systems (OS) now have native software package managers — APT, YUM, Zypper, and Pacman on Linux, Homebrew on macOS, Nuget/Chocolatey on Windows, and pkg on *BSD — and software vendors try and integrate well into those native OS ecosystems in order to provide a more seamless integration with other OS packages and to make the management of software stacks easier for operations and administration teams. There are myriad of reasons to use the native OS package managers, for example:

  • There's a central set of repositories of all software for the system.
  • All software can be easily discovered and managed with the same set of tools.
  • Packages can automatically manage and enforce any dependencies.
  • Packages can integrate with system security features such as SELinux.
  • Packages can integrate with system service management frameworks such as Systemd.
  • Packages can easily be kept up to date through automated upgrades.

It's for these reasons, and many more, that we wish to direct more of our available resources toward creating additional native OS packages and improving existing ones.

MongoDB Tar Packages

We have one specific legacy artifact around from the time when we did not integrate with these native OS package managers, nor even build tars for specific OS variants. This legacy artifact is our Legacy Generic x64 Linux Tar package — a legacy that we are planning to End-of-Life with MongoDB 4.2. The primary reasons for doing so are:

  • It has an opportunity cost because it takes up finite resources that can otherwise go toward providing MongoDB users with other value.
  • The generic nature of these packages make it so that we cannot dynamically link in other system packages within our build system, most notably OpenSSL and cURL (which is used for several MongoDB features).
    • This means that these binaries do not support SSL and should not be used in production.

However, tar packages do still provide user value and meet some use cases that native package managers can still struggle a bit with, for example:

  • Installing software without elevated system privileges.
  • Installing and maintaining many versions of a piece of software simultaneously.
  • Installing software within a single self-contained directory.

It's for these reasons that we will continue to provide tar (and zip) packages for specific OS variants — for example, RHEL 7 x86_64 — in order to meet these use cases. We believe that these packages will allow us to meet those (shrinking) use cases where tars are still a great solution, but without incurring the security, performance, and feature loss penalties that the Legacy Generic x64 Linux Tar package does.

Request for Comment

We wanted to announce our intentions well before the 4.2 GA release in order to give our users ample time to consider this change and provide us with feedback. We'd love to know what specific pains this may cause for you and how we might try and better address them. For example:

  • By adding official MongoDB, Inc. support for additional OS variants.
  • By working with OS package maintainers to add MongoDB packages where official MongoDB, Inc. provided ones do not exist.

So please let us know! You can comment here on the post, open a ticket in Jira, send an email to the user mailing list, grab me on the community slack channel, or send me a direct email. We need your input and look forward to some good discussions on the topic. This decision is not final and you as a valued MongoDB user have an opportunity to help drive our product direction.

THANK YOU for using MongoDB!