Bug#883133: general: Add new package header Upstream-Version:
- Date: Sat, 2 Dec 2017 11:08:32 +0000
- From: Simon McVittie <smcv@xxxxxxxxxx>
- Subject: Bug#883133: general: Add new package header Upstream-Version:
On Sat, 02 Dec 2017 at 06:06:29 +0200, Victor Porton wrote:
> A script may be specified by a user of my software by the URL of the
> script and name and version range of the interpreter (simplified
I don't see how a new Upstream-Version field would help you to do this.
Let's suppose you want to support dpkg-based systems like Debian and
Ubuntu, and RPM systems like Fedora and openSUSE (and probably others
but those are enough to demonstrate my point).
To get the upstream version from dpkg, right now, you can query the
dpkg database for the Version in a dpkg-specific way, then parse the
version number in a dpkg-specific way to extract the upstream part. A new
Upstream-Version field would eliminate the second part (in 5 years or so
when all packages had it), but you would still need to write dpkg-specific
code to get the Upstream-Version field, so you've gained
nothing. Similarly, if a similar feature request in RPM was successful,
you'd still need to query the RPM database to retrieve the upstream
version from there, so you'd still need RPM-specific code; not needing
to apply RPM-specific parsing to the version doesn't avoid that.
If you want to avoid packaging-system-specific code, you'll need to
query version numbers in a way that only relies on the upstream
software, like python -c 'import sys;print(sys.version)'.
> To choose an installed interpreter, then my program should check if
> "python2.7" is installed, if its version is in 2.7.1 - 2.7.14 range. It
> also to check if "xsltproc" is installed and its version.
> For this I need the upstream versions of "python2.7" and "xsltproc".
Version ranges should usually be of the form "package >= version",
not "package >= version1 && package <= version2". If an upstream regularly
breaks backwards compatibility, then it should provide versioned entry
points (like python2 vs. python3), or at least provide a concept of a
major version within which compatibility will not break (in the case
of Python that's the first two version components, python2.7 vs
python3.4 vs python3.5).