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.