Web lists-archives.com

Re: Different versions for binary packages from same source

On Tuesday, December 26, 2017 11:07:32 AM Ryan Kavanagh wrote:
> Hi,
> Is there a good reason not to have a source package build binary packages
> with different versions in the following circumstance?
> The prerex source package (sources obtained from CTAN) provides a LaTeX
> package for drawing charts. It also contains two tarballs: one with the
> sources for the prerex utility (a readline interface for creating these
> charts) and one with the sources for the vprerex (a Qt utility for doing
> the same). There are three different versions at play (the outer LaTeX
> package's, prerex's, and vprerex's) and vprerex/prerex are not released
> simultaneously/at the same time.
> Until now, both the prerex and vprerex binary packages have used the source
> package's version. I would like to make each use the versions of their
> respective tarballs so as to better track upstream development.
> I've checked the policy (section 3.2[0]) and found no guidance, and I've
> discovered that android-sdk-meta does something similar[1]. My hesitance
> stems from suspecting that an implicit assumption in lots of our
> infrastructure is that binary packages and their source packages have the
> same version.
> Happy holidays,
> Ryan
> [0] https://www.debian.org/doc/debian-policy/#the-version-of-a-package
> [1] https://unix.stackexchange.com/a/283178/149551

gcc-defaults has long had a source version that's disconnected from the binary 
versions, so it's not alone.

Scott K

Attachment: signature.asc
Description: This is a digitally signed message part.