Linux packages naming

Solution 1:

Most distributions only allow one version of package xyz to be installed at a time. If libxyz is a library, where incompatible versions 1 and 2 are in use at the same time, they can't just call the packages libxyz-1 and libxyz-2, installing the later will delete the former. Thus some other naming scheme is needed so you can have libxyz1-1.5 (upstream 1.5) and libxyz2-2.1 (upstream 2.1) installed at the same time. This obviously requires further distinctions at the individual file names of the contents of the package, but that is another kettle of fish.

Solution 2:

Linux has a mechanism for versioning that does not require renaming of the package. It is used for glibc, as you can see in the post How exactly a system might break by updating glibc?.

But this requires lots of work on the part of the developers, mainly in that glibc must backward support all the previous versions of all its functions.

Not many developers can guarantee to support all their software, present and past, or to invest the same level of development time as is invested in glibc.

Packages like libavcodec56, libavcodec57 etc. do not guarantee backward support, and versions might not be entirely compatible, so programs that use them might need to be modified when changing versions. The fact that the version names are different is the best indicator of that, and this is done by design.