Sections of the Mint repository

The Linux Mint repositories contain all the software developed by us, imported by us or in a more general way, all the software we decided to maintain. If a particular package is in a Linux Mint repository it gets a higher priority than if it is in an Ubuntu repository, as a consequence, packages which are maintained by Linux Mint don’t directly get updates from Ubuntu, even if a newer version is put in the Ubuntu repositories. This is called APT pinning and it consists in always preferring Mint repositories over Ubuntu ones for particular packages, no matter what their respective versions are.

Linux Mint repositories are organized into different sections, which you can enable or disable based on your needs:

main: This section contains all the software developed by Linux Mint. For example: mintUpdate, mintInstall etc…

upstream: This section contains packages coming from upstream (in most cases from Ubuntu) which are patched, modified or repackaged by Linux Mint. For example: Firefox, Tomboy..etc

import: This section contains software which comes from 3rd party developers and for which there are no (or outdated) upstream packages. Linux Mint packages these software applications and “imports” them into this section. Examples: Opera, Picasa, Songbird, Sunbird, Frostwire.. etc. In some cases the imported software is already packaged (some packages come from for instance).

community: This section is disabled by default. We haven’t used it much so far but we’re planning to do so more and more. Sometimes, members of the community package things up and ask us to include additional software in our repositories. We’re planning to include these packages into this section.

backport: This section is disabled by default. We haven’t used it much either, but we will use it more and more, especially with Elyssa, which is an LTS semi-rolling release. When a new version of a package becomes stable it is usually included in the repositories of the latest release. We’re also planning on porting these new versions back to Elyssa so Elyssa users can enjoy up to date desktop components until the next LTS release. The backport section is where we’ll include these new versions.

romeo: Packages don’t stay in Romeo, they get there so we can test them and when they’re stable enough they go to another section. Linux Mint’s Romeo is like Debian’s Unstable, Mandriva Cooker or Fedora Rawhide… The only reason for you to use Romeo is to help us test new packages. For instance Romeo currently contains Flash 10 Beta 2, mintInstall 4.0 and will soon get mintUpdate 2.8. Romeo is quite unstable.. and as our stable releases carry female names we decided to give our unstable branch the name of a famous heart-breaker.

Finally, there is a website for the repository where you can see which packages and versions are in which section, where you can download debs and even source code:


  1. Nice informative post!
    I didn’t get the “Romeo” thing until I read it here, so yeah… Makes sense 😀

  2. am glad to hear that for the backports

    ubuntu essentially forces people to upgrade every 6 months, since their backporting is extremely lacking.

    IMHO if an LTS is really working well for you, that person should have the option to stick with it at least till the next LTS.

    this is a problem for linux in general, but i congrat Clem for the idea of making it as semi-rolling as possible.

    this is a good thread that points out these problems with ubuntu:

  3. I think it would be a good idea to make a top 10 or better top 25 softwares, which should be always be updated as soon as possible – for example within one day. Examples for this packages are: Firefox, Thunderbird/Evolution, OpenOffice, Miro, Frostwire ….


  4. Shahin: That’s a good idea. I wouldn’t say a day but I’d like to have such a list and eventually make a meta-package called lts-desktop to keep track of them.

  5. Pingback: The Linux Mint Blog » Blog Archive » Weekly Newsletter - Issue 53
  6. Clem, please refer to my last comment in your previous post. However, I’d like to take something into account, and that is to ask you why not rename the mint tools to something verbal-based instead of noun-based? For example, instead of mintUpdate, we could use mintUpdater. I think that emphasizes the function even more, since many people who come from other operating systems in search of ease-of-use are used to look at the programs as executers of something, for example, “mintInstaller” would easily be identified as the program used to install. As the installer.

    I don’t think it would cause confusion, however, the last word is up to you.

Comments are closed.