I want to understand how the APT package is managed in general, considering the following situation I got into today:

I was trying to add MongoDB to my Debian machine. apt search mongodb showed good-looking results, and before attempting to install I read the MondoDB documentation which stated:

Follow these steps to run MongoDB Community Edition on your system. These instructions assume that you are using the official mongodb-org package -- not the unofficial mongodb package provided by Debian -- and are using the default settings.

From this, I understood and was surprised that what I get from Debian's apt install is unofficial by the developers of the app. This sounds worse than "not recommended".

I do understand Debian APT package repository tends to show old versions and is never meant to catch up with latest leading edge updates. There are so many ways to deal with this, but now I'm concerned by the words unofficial. Does this mean, packages related to MongoDB (or any other app) on the APT repository isn't officially approved by the app developers? Or was it officially shipped by the developers but "avoid because it's not the latest version"? Or did someone (some entity?) copy from the official installation package and paste it to APT?

I'm not trying to understand just this specific case with MongoDB. Instead I want to understand the overall "politics" on applications and APT. How does it work, how was it supposed to work?

If this is a noob question then I'm sorry, but I couldn't find a good explanation online. Any links or reference would be appreciated.

  • The developers most likely have tested their own packages, but not the Debian distributed ones. Jan 18, 2022 at 6:40
  • Is it pure Debian? Not a Linux distribution based on Debian? Jan 18, 2022 at 18:32
  • @PeterMortensen What I meant by "Debian" here is the Debian I download from Getting Debian. I assume the MongoDB documentation means the same, as there is another page dedicated to Ubuntu. In terms of the answer I seek, I was asking about APT in general so the answer doesn't need to be specific to Debian at all.
    – dungarian
    Jan 18, 2022 at 23:22
  • 2
    For what it's worth, I wouldn't agree with your perception of "unsupported" as worse than "not recommended". My impression is that "unsupported" (in the world of open source) means something like "you can try to use it, but you're on your own if anything goes wrong", whereas "not recommended" often (though not always) means "we think what you're trying to do is a bad idea and something probably will go wrong".
    – David Z
    Jan 19, 2022 at 6:38

4 Answers 4


Packages in all distributions (not only Debian) are usually not packaged by the developers of the application, but by the members of the community of the distribution, usually called packagers or package maintainers. Sometimes the application developer can be also the packager in some distributions but it isn't a rule and developers definitely cannot maintain their application in all distributions (for example I maintain my software in Fedora, but it is packaged by someone else in Debian).

When it comes to "approval" and being "official" or "unoffical". We are talking about free software here, the licenses allow distributing the software so you don't need anyone's approval to package software for a distribution. The developers may disagree with the way their software is being packaged and shipped but that's all they can do.

I'm not sure what makes the package (un)official. I guess all packages are in theory unofficial because they are made by a third party. It probably depends on your definition of being (un)official.

One thing that can cause tension between packagers and developers is the release cycle. Distribution (especially "stable" distributions like Debian Stable or RHEL/CentOS) have their own release cycle and their own promises about software and API stability which is usually different from the upstream release cycle. This is the reason why you see older versions in your distributions, usually with some bug fixes backports. And sometimes upstream developers don't like this, because they get bug reports for things that are already fixed but not backported etc. And sometimes packagers make their own decisions about compile time options and other things that change (default) functionality of the software, which can be also annoying. So developers tell you something like "Use our 'official' packages instead of your distribution packages" and it's up to the user to decide what is best for them.

  • 8
    And the flip side is that distributions will support only their packaged versions, particularly for things that e.g. interact with the init system. So you get to decide whether you want support from the originator or from the packager. Personally, I avoid installing from original sources unless I can be sure it installs into /usr/site, so as not sabotage dpkg's idea of what's present on the system. I'll normally build the (perhaps modified) package and install that. Jan 16, 2022 at 9:40
  • 20
    /usr/site is a new one to me. I usually see /usr/local used for this.
    – Stewart
    Jan 16, 2022 at 11:30
  • 2
    The situation here is made more complex by MongoDB’s license change (see my edit to Jörg W Mittag’s answer for details). Jan 17, 2022 at 9:18
  • @Stewart You are correct; /usr/site should not exist, according to the Linux FIlesystem Hierarchy Standard. Jan 17, 2022 at 9:37
  • 7
    Worth noting: application developers tend to be focused entirely on their application and their application alone, often assuming that their app is the only important thing running on a system - and simply don't care about integration with the rest of the system (some are even overtly hostile to the notion that their app has to fit within an existing system), or about how a user might safely upgrade or uninstall their app without losing data. Many think that brawndo-installer ("curl URL | sudo bash") is an appropriate way to install software rather than a gaping security hole.
    – cas
    Jan 17, 2022 at 14:14

The main question is: "official" according to whom? Whether or not something is "official" depends very much on which "office" you are asking!

The packages distributed by the MongoDB developers are the "official" packages according to the MongoDB developers. The packages distributed by the Debian developers are the "official" packages according to the Debian developers.

Neither of the two is more "official" than the other in some global sense.

There are many possible reasons why the distribution packages may differ from the vendor packages:

  • The vendor packages do not support all architectures the distribution supports. For example, MongoDB only provides packages for Debian on AMD64. But Debian supports not only AMD64 but also armel, armhf, arm64, x86, mipsel, mips64el, ppc64el, and s390x. So, this means that if you use Debian on RaspberryPi (ARM64), there is no package from MongoDB.
  • The vendor packages do not support the latest distribution release. The latest release of Debian is Debian 11, but MongoDB only offers packages for Debian 9 and 10.
  • The vendor packages are not supported for the same time the distribution is supported. For example, Debian releases are typically supported by the Debian security team for one year after the next release (which usually works out to roughly 3 years). After that, there is a team of volunteers within the Debian community called "Debian LTS", which take over maintenance for up to 5 years after the original release. After that, there is third-party commercial project called "Debian ELTS" which offers support for up to 7 years after the original release. And after that, you can hire a Debian Consultant for additional support, as long as you want.
    This means, for example, that Debian 8 still has ELTS support, but there are no packages from MongoDB for it.
  • The distribution developers guarantee that every package they ship works together with every other package they ship over the entire lifetime of the release, they guarantee that every bugfix they ship will be backwards-compatible, etc. Typically, vendors do not make the same guarantees for their own packages. E.g. if you use the MongoDB package and an update breaks some random other package, then you will not get support from Debian (because you are not using their package), and it is possible that the MongoDB developers will simply not care about that random other package enough to provide a bugfix. (I am not saying that the MongoDB developers specifically don't care, I'm saying it is possible that the developers of some vendor might not care.)
  • Sometimes, vendor packages simply violate some guidelines for how to package software for a particular distribution, so that distributions need to provide their own packages. E.g. some distributions have strict rules about which kinds of files are to be stored in which directories, which directories need to be read-only, etc.

Now, it turns out that in this particular case, Debian has actually stopped providing their own packages because MongoDB changed to a different license. The latest version of the mongodb package is in Debian 9. Debian itself no longer provides packages for MongoDB in Debian 10, Debian 11, or the under-development Debian 12. However, the package that is in Debian 9 is available for AMD64, ARM64, x86, and PowerPC 64 bit little-endian, whereas the package from the MongoDB developers is available for both Debian 9 and 10, but only for AMD64.

In general, the main reason why distributors provide their own packages is because the distributors have a different set of concerns and constraints than the software vendors, and thus the packages provided by the software vendors often do not satisfy those concerns and constraints.

Remember, most distribution packages are created by unpaid volunteers, and most distributions would like to provide more packages but lack the manpower to do so. If there was a way that they could just take the packages from the software vendors unmodified and drop them into the distribution, they usually would do that, and instead focus their efforts elsewhere.

  • 1
    @Stephen Kitt Thanks, I had a vague recollection it was a license issue. Jan 17, 2022 at 9:21
  • 2
    This. Further, the whole purpose of having a distro like Debian is not to have to trust the upstream software provider and their installation procedures. In the old days of Unix (and on Windows still to this day), the norm was that the provider of a piece of software ships you an installation program based on their assumptions about what your system might be like, which may or may not be correct, and it might make changes to your system configuration that are in their interest but against yours. Jan 17, 2022 at 23:11
  • 3
    By having a distro consuming their upstream and providing a package to you, there's a third party between you and the original software whose interests are mostly aligned with the wellbeing of you and your system, not potentially conflicting commercial interests. Jan 17, 2022 at 23:13
  • 1
    @dungarian: I would say it's the whole reason distros package a complete set of application software rather than just "the OS". They could of course just do a base OS and desktop and tell you to get everything else as third-party package files from the software upstream, but they don't, because that would be abdicating their responsibility to shield the user. (Note: recent trend is for some distros to bail out on doing this and instead encourage semi-sandboxed or containerized apps. This does not provide same protection.) Jan 18, 2022 at 15:42
  • 1
    Re (2), I didn't mean to classify distros in groups there, just that I meant "distro" in the sense of what folks think of as "a Linux distro" rather than other possible meanings of the word. Of course there are ones that are more minimal and don't include application software but it wasn't my aim to get into that. Jan 18, 2022 at 15:49

Distro maintainers may apply their own set of patches which the upstream may not endorse. This may lead to a situation like this.

Distros may also have certain policies in regard to the versions of software they provide which may not agree with what the original creaters had in mind.

Debian has had many related incidents:

Open Source is not so rosy once you get to know it better.

Are Debian APT packages not officially supported or acknowledged by application developers?

As a rule of thumb, the answer to this question is "no" and it's not just Debian, it applies to other distros as well.

For instance, check https://bugzilla.kernel.org

Please use your distribution's bug tracking tools This bugzilla is for reporting bugs against upstream Linux kernels.

  • Given that that are well over 100 open source licenses recognized by OSS, I agree that the future is not rosy. Knowing your license requirements sometimes takes a lot of work.
    – doneal24
    Jan 15, 2022 at 20:39

Does this mean, packages related to MongoDB (or any other app) on the APT repository isn't officially approved by the app developers?

Indeed. "Free software" (in the GPL sense of the word) means that anybody can grab your source code, modify it, and then redistribute it without your approval or even without informing you at all.

Developers of pretty much any open-source project ask users to try the latest available version before reporting a bug. In that sense, any third-party packages are unofficial: if they work, good for you, if they don't, you should report this to the package maintainer, not the developers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .