On Thursday, January 22, 2026 1:11:33 AM Mountain Standard Time Ole Streicher
wrote:
> Hi Andreas,
>
> Andreas Metzler <ametzler@bebt.de> writes:
> > On 2026-01-21 Ole Streicher <olebole@debian.org> wrote:
> >> The original glueviz package had the version number 1.0.1+dfsg-2 in
> >> bookworm (oldstable), while the version number of the upcoming package
> >> is 0.4.1-1. Decreasing version numbers is not allowed between oldstable
> >> and unstable/testing; on the other hand it is useful to keep the familar
> >> package name (it is factically the same binary package). Therefore, I am
> >> proposing to use epoch 1 for new new glue-qt source package.
> >
> > How about:
> > src:glue-qt 0.4.1-1
> > binary python3-glue-qt 0.4.1-1
> > binary glueviz 1.0.1+really0.4.1-1 (i.e. 1.0.1+really${binary:Version})
> >
> > Source and binary packages do not need to share the version number.
>
> This is just a kind of "Fake-epoch".
>
> For a temporary solution (like a temporary rollback), this would be a
> possible workaround, but our policy states (5.6.12.2) that
>
> | The presence of +really in the upstream_version component indicates
> | that a newer upstream version has been rolled back to an older
> | upstream version.
>
> which limites "+really" to rollback situations (which is not the case
> here; this situation is permanent).
>
> Our policy states that epochs are to help resolve the problem where the
> upstream version numbering scheme changes, and I think my problem is at
> the same level.
>
> One *coould* think about limiting the epoch to glueviz (having
> python3-glue-qt still epoch 0), but I don't see how this would be better
> than having all packages the same epoch. In opposite, that would
> complicate the packaging workflow and the handling of possible future
> epoch changes. Also, one cannot use "python3-glue-qt (= ${binary:Version})"
> anymore in d/control for dependencies.
>
> I'd still propose using an epoch here.
As the maintainer of a package (courier) that legitimately has to use
different versions for some of the binary packages, I agree that using an
epoch is, by far, the preferred solution. An epoch creates far fewer
problems. I would only use different versions for binary packages if there is
no other possible solution.
--
Soren Stoutner
soren@debian.orgAttachment:
signature.asc
Description: This is a digitally signed message part.