How can I store several versions of the same package in PPA

It is the normal nature of Debian/APT package repositories, or which PPAs are one implementation, to store one version of each package per distribution series.

If you have separate environments with different needs, you might consider using a separate PPA for each.

If you need an arbitrary choice of which version of a package is installed on any given machine, the usual technique is to embed the version into the source and binary package *name* - e.g. in Ubuntu, when OpenSSL was updated to 1.0, and some apps still required 0.9.8, an "openssl098" package was added alongside the default "openssl":

https://launchpad.net/ubuntu/+source/openssl
https://launchpad.net/ubuntu/+source/openssl098

If you'd like to discuss the issue further, please clarify why you need separate versions simultaneously available.

It is strange for me to hear that it is a normal nature to store one version
of each package.

I did 'apt-cache showpkg openssl' on my 10.04 and see 2 different versions:

Provides:
0.9.8k-7ubuntu8.6 -
0.9.8k-7ubuntu8 -

I will try to explain why do I need this feature.

I have an package "app". It depends on some library package "lib". I have
"lib" and "app" packages in ppa (or some other repository). I can get the
newly installed ubuntu, add needed repositories and install "app" package.
As it depends on "lib" package, it will also be installed.

A bit later a new version of library "lib" was released and placed to the
repository. I get the new ubuntu box, install "app" as well as the new
version of "lib". But in the new version of "lib" there is some changes
that break the work of "app" package.

The solution for this is to specify in the "app" package the exact version
of "lib".

You are right, I can specify the lib version in it's name, so it will be
something like "lib-1.00" and "lib-2.03", but this seems ugly for me.
In deb package there is explicit place to store version, why not to use it?
There should be some version anyway, so what to put there? Should it be
always "1" then it it will be ugly in "dpgk -l" output:

ii lib-2.03 1.00 some lib

Or should it contain the same version as it is in the package name? Then the
question is why we need 2 Fields storing the same information?

ii lib-2.03 2.03 some lib

You see two versions of openssl because one is in "lucid" and the other in "lucid-updates". There's only one version provided by each of those separate "repositories".

Concerning your lib/app situation:

1. Either app needs to be updated to work with the new version of lib.

2. Or, two versions of lib need to be maintained in parallel for a while.

If you go for option 2, then consider the following situation:

Suppose you have an archive containing lib 1.0 and lib 2.0. Now, there's a minor bugfix release out for both major series. You need to prepare and upload 1.01 and 2.03. How is the repository management software going to know that 1.01 supersedes 1.0 and 2.03 supersedes 2.0? The answer is that rather than trying to build complex rules on the interpretation of the versions alone, package repositories opt for the simple but flexible rule of using the package name as the sole determinant of what supersedes what, and package names being modified to indicate different streams of development when multiple must co-exist in a single repository.

So, in this sort of circumstance, you'd have something like lib-2 2.03. (If you wanted 2.01 to be replaced by 2.02, and in turn be replaced by 2.03 within the repository. If, on the other hand, you wanted all of those to be present in the repository simultaneously, you'd go for lib-2.01 2.01, lib-2.02 2.02, lib-2.03 2.03.)