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 > explanation).
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). smcv