On Thursday, January 22, 2026 1:11:33 AM Mountain Standard Time Ole Streicher wrote: > Hi Andreas, > > Andreas Metzler <[email protected]> writes: > > On 2026-01-21 Ole Streicher <[email protected]> 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 [email protected]
signature.asc
Description: This is a digitally signed message part.
