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.
Best
Ole
