Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

While working with Ubuntu and other Debian-based distros, I've noticed that packages in the software repos often contain the major version number.

For example,

  • Apache: apache2
  • Tomcat: tomcat7
  • PHP: php5
  • Wine: wine1.4
  • MySQL: mysql-server-5.5

I notice however that there's no apache1 package available, and similar for the rest. If the name of the package changes with updates to the software, doesn't that get in the way of one of the major goals of package management (easy upgrades)?

If Apache 3 comes out tomorrow, am I going to have to install the apache3 package manually if I want to upgrade?`

share|improve this question
add comment

2 Answers

up vote 23 down vote accepted

Packages are named like that where there is (or was) a need to ease the transition between two major versions of a package, and the time needed to do so is expected to be long. During the transition period, both new and old versions are kept available, with the understanding that at some future time the older one(s) will be discontinued.

Sometimes the transition period is happening during the system release you're currently using. For some packages, it happens often enough that you can expect to see transitional package versions in every new system release. Software development tools often fall into this category, since upgrading to new tools on the same schedule as system releases may not be practical. My company's dependence on particular versions of GCC, Autoconf and Perl might be on a 5 year cycle, while my OS might be on a 3 year upgrade cycle. It therefore makes it easier for me to adopt new OSes if it includes my older versions of some packages in addition to whatever was current at the time the new OS was being developed.

Other times, these major version changes happened long ago, in the past, and now everyone is on the current version. This is the case with Apache, for example. The 1.3 to 2.0 change was a far bigger deal from a compatibility standpoint than any of the 2.x version changes, so once everyone was off 1.3, there was no longer a need to keep offering multiple Apache versions within a given OS release. But, once you've got everyone using the apache2 package, there isn't a very good argument for renaming it back to just apache. That would cause an unnecessary upgrade hassle. Besides, where there was a perceived need in the past to provide two parallel versions temporarily, the need will probably recur in the future.

This package naming practice typically happens only with libraries or important core packages. For more peripheral packages, you're expected to just upgrade to whatever's current at the moment.

Libraries are more commonly treated this way than applications because, by their nature, other packages depend on them. The more popular a library is, the more impractical it is to demand that every other package depending on it be rebuilt and relinked against it purely so that the library can be step-upgraded to a new major version without this transition period.

Often when an application is being treated this way, it is because it contains a library element. For example, Apache is not just a web server, it also provides a development API for the plugins. (mod_foo and such.) If someone has an old mod_something linked against the Apache 1.3 plugin ABI and hasn't upgraded it to use the newer 2.0 API, it's convenient if your OS continues to offer the old Apache 1.3 until all the plugin creators have a chance to update their plugins.

share|improve this answer
add comment

From what I have seen, reasons for this are:

  • Help migration in major releases of packages: when PHP 5 was released, maybe one needed to have a PHP 4 install. This allows one to have a choice between versions (at least until the older version is obsolete).

  • Keep providing updates to an older version of a software (e.g. after Apache 3 is released, might be needed to patch Apache 2) without upgrading it to a newer major release.

E.g. the Linux kernel has (as of today) the stable versions 3.5, 3.4.7, 3.2.24, 2.6.35.13 etc.... If you're running 2.6.35 on a system and you want to keep it up-to-date, but not upgrade this kernel, you can install the adequate package.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.