Ok, one more correction. I looked at dpkg --info kdelibs4-dev_3.5.10.dfsg.1-2ubuntu7_amd64.deb Version: 4:3.5.10.dfsg.1-2ubuntu7 epoch matches major version number in name But, that doesn't work for kdelibs5-dev_3.5.10.dfsg.1-2ubuntu7_amd64.deb, where dpkg --info kdelibs5-dev_4.3.2-0ubuntu7_amd64.deb Version: 4:4.3.2-0ubuntu7 So, I'm going to say that the epoch is just dropped from filename of the deb, at least for Ubuntu 9.10 as I can't find any debs that have ':' in the actual filename. On Fri, 2009-12-04 at 14:25 -0600, Luke Imhoff wrote:
On Fri, 2009-12-04 at 13:21 -0600, Luke Imhoff wrote:
Ok, I think this is a real bug on the server, but just let me know if it's some policy I'm unaware of (again ;-)):
libattr1's version in a bdep tag is 1:2.4.43
the full bdep is
<bdep arch="amd64" name="libattr1" notmeta="1" preinstall="1" project="Ubuntu:9.10" release="3" repository="standard" version="1:2.4.43" />
The full deb name on the server is
libattr1_2.4.43-3_amd64.deb
The same thing happens with other debs that have numbers at the end of their names like kdelibs4-*. Somehow it's grabbing both numerical pieces and then joining them with ':'.
Where in the obs-server or build code is the version parsed out? I can fix it, I just don't know off hand where in the perl the parse is located.
Once again, the data is correct, it just doesn't match the naming scheme for the deb package. If you look at the Version reported by dpkg --info libattr1_2.4.43-3_amd64.deb it says:
Version: 1:2.4.43-3
I guess that means if version has a ':' in it, then the file name calculation needs to be special cased so that the bit before the ':' gets added to the name, while the bit after gets created as the normal version.
Michael, do you know if this is a standard for Versions with ':' in them that can be safely assumed? I'm not sure how else to derive the package filename correctly from the bdeps.
On Fri, 2009-12-04 at 11:32 -0600, Luke Imhoff wrote:
Ok, if that's the policy, that's fine then. osc still needs to be changed to not key off of the 'release' attribute to determine the whether to use rpm or deb format then.
On Fri, 2009-12-04 at 11:27 -0600, Michael Schroeder wrote:
On Fri, Dec 04, 2009 at 10:21:39AM -0600, Luke Imhoff wrote:
Seems there's a parsing error on the server too:
<bdep arch="amd64" name="bash" notmeta="1" preinstall="1" project="Ubuntu:9.10" release="5ubuntu2" repository="standard" version="4.0" />
debs never have releases, it's all in version, but bash's version is 4.0-5ubuntu2, so the server is miss parsing the version as a version and release.
The server splits it into version-release if the string contains a '-', otherwise it sets only the version. I think this makes sense, the upstream bash version is "4.0", "5ubuntu2" is some release scheme from ubuntu.
This is pretty much in line with the Debian Policy Manual, which states:
5.6.12 Version The version number of a package. The format is: [epoch:]upstream_version[-debian_revision]
Cheers, Michael.
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org