Ubuntu
apt package

cannot distinguish version from revision in package Version string where hyphen is not present

Asked by stephen quintero

Hello,

I am trying to parse Ubuntu package Version strings into version and revision, and also distinguish the upstream version where it may be different from the parsed version.

As I understand from the Debian policy manual a package Version string should include the revision, if any, appended after a hyphen to the version, while the version itself should represent the upstream version, so that apache2 2.4.10-8ubuntu2 indicates:

upstream: version 2.4.10
revision: 8ubuntu2 where 8 indicates Debian revision 8 and 2 indicates Ubuntu revision 2

Many packages appear not to conform to this. For example:

apt 0.8.16~exp12ubuntu10 (from ubuntu 12.04)
apt 1.0.1ubuntu2 (from ubuntu 14.04)
apt-clone 0.3.1~ubuntu11
apt-listchanges 2.85.13ubuntu2

None of these have a hyphen to separate any revision. Take the last example. Does it indicate version '2.85.1' revision '3ubuntu2', or version '2.85.13' revision 'ubuntu2', or just version '2.85.13ubuntu2' in which case it is not the upstream version at all.

If these Version strings are considered conforming to spec, then these packages have no revision, and the versions are as stated, in which case the upstream version is still not apparent (determinable).

Other package Version strings do have a hyphen separating a revision from the version, but the version is still obviously not the upstream version. For example:

account-plugins 0.11+14.04.20140409.1-0ubuntu1
xchat-gnome 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu12
x11proto-randr 1.4.0+git20120101.is.really.1.4.0-0ubuntu1

In summary, my questions:
1. If a Version string such as that for apt 0.8.16~exp12ubuntu10 has no hyphen, is there really no revision, or is the Version string malformed?
2. How does one distinguish the upstream version where any parsed version from the Version string is clearly different, e.g. versions "2.85.13ubuntu2" or "0.30.0~git20131003.d20b8d+really20110821"

Any light you can shed on this would be much appreciated.

Best regards,

Stephen Quintero
<email address hidden>

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu apt Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
stephen quintero (step5en) said : 		#1

Hi,

I did receive a clarification on this question. The situation appears complicated because Ubuntu receives a package which may or may not include a hyphenated Debian revision. Regardless, if Ubuntu modifies the source, it appends ubuntu* (no hyphen). This is what I did not discover through searching and is the origin of my question.

If I understand correctly, to deconstruct the result in reverse temporal order:

1. To find an Ubuntu revision, if any, chop right on ubuntu*
2. To find a Debian revision, if any, chop right on hyphen
3. Chop right on ~ and + to remove what is not clear yet
4. What remains is the original upstream version (optional epoch) from which this chain of transformation emerged (it may be a Debian product or originate upstream of Debian)

The function of ~ and + are still not entirely clear to me. It seems:

1.0~foo means derives from version 1.0 preceding commit foo
1.0+foo means derives from version 1.0 succeeding commit foo

So that 1.0~foo+really.bar means?

Best regards,

Stephen Quintero

Revision history for this message
Manfred Hampl (m-hampl) said : 		#2

I think I can add a piece of information to the puzzle (maybe even adding more confusion):

The xchat-gnome version number 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu12 in trusty is a special case.

The intentions were to upgrade from
1:0.30.0~git20110821.e2a400-0.2ubuntu12 to
1:0.30.0~git20131003.d20b8d-2ubuntu1
but that version turned out not to work satisfactorily.

To revert to the old version, a new package was created with a version number that was higher than the newer (not working) one, but that still showed that the contents in reality are the older package.

Thus a version number 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu12 was introduced.

I fully agree with you that this numbering does not fit into any scheme, and does not support an automatic split into pieces as desired.

(for this single case see also bug 1272455 )

Can you help with this problem?

Provide an answer of your own, or ask stephen quintero for more information if necessary.

To post a message you must log in.