Re: Bug#883133: Bug#883134: general: Add new package header Upstream-Version:
Michael Stone <mstone@debian.org> writes:
> On Sat, Dec 02, 2017 at 09:28:21PM +0500, Andrey Rahmatullin wrote:
>> On Sat, Dec 02, 2017 at 11:18:53AM +0000, Ian Campbell wrote:
>>> On Sat, 2017-12-02 at 06:06 +0200, Victor Porton wrote:
>>>> For this I need the upstream versions of "python2.7" and "xsltproc".
>>> The upstream version of a Debian package can be deterministically
>>> extracted from the package version, see
>>> https://www.debian.org/doc/debi an-policy/#s-f-version for the format.
>> Unless it's 4:2.0+really1.1.
> Yeah. The language about avoiding epochs has (IMO) led to some crazy
> suboptimal versioning as an alternative, to the point that it's not
> generally possible to assume that the real upstream version number can
> be extracted from the debian version.
There are various other edge cases as well: repacked upstream releases,
packaging of an upstream VCS snapshot, upstream version "numbers" that
start with letters and therefore aren't valid Debian version strings, and
so forth.
The original reporter is correct that we don't preserve the actual
upstream version number somewhere in our packaging in every case. You can
get it from the package version in probably 95% of the cases, but the
remaining 5% require a lot of esoteric knowledge of Debian conventions and
possibly that specific package.
That said, I'm still not sure what the original problem statement is.
When would it be useful to programmatically extract the original upstream
version number? The other Debian use case that I'm aware of for this is
uscan, which does quite a bit of other work and wouldn't particularly
benefit from an Upstream-Version field.
There is a gap here, but why is it worth the packaging overhead to fix?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: