On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote:

The upstream minor versions are always determined by letters, so I'm unsure how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints?

This is a real sad interaction between the letters and the + in this
case.
Clearly the best solution would be to not need to repack anymore, this
would throw the problem away. What's even the point of carrying the RFC
in the tarball nowadays?

Another solution would be to change the character used to separate the
'dfsg' string. + tends to be preferred, but you could use ~ with the
same result most of the time, and it would likewise fix the problem:
% dpkg --compare-versions 1.3.8a~dfsg-1 gt 1.3.8~dfsg-1
=> TRUE

Lastly, you could convince upstream to *always* release their first
release with the trailing character, so there are not release that end
with a number, similar to tzdata.



That said, for this 1.3.8 case you are quite stuck, as you can't do any
of the above. The only option that comes to my mind is to just mess up
the upstream version string to something like 1.3.8.a+dfsg, and keep at
that until 1.3.9 comes out.

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmUogiUACgkQCBa54Yx2 K60haBAAm7UjDZUoBhuQenshRSu9Xdqs57LlPD79waBSnNPC++nHOWfViJEQXQ5g LeihcbGU3P4RAJCDXKWU828mfEusZDq29L2yzz3lFzrInFf/m7Z6eFOgQjF6qSlV sQeHyZGaaCFW/IxtIOOFXYdmpUKBrEgU1r648QogGMc+YF8v3ApEQvyWVts6Efzv CnQbIFhLfrk4KXL0ao0DCPbMfxSWNm3lCBLXDDYW4S5CaqqzaRAc0Urb9aHm4oIZ 34lK1o96XSC6tlNRr7SizLolJ/r+cmCQt0yu5kp3D+uu1IVRIFTWaGbqZ2Akd3le cAKbGUS/iDCuSCN654+nCWkeFfNjBWZTonc1uV3DcKUIxebQCb/OpJCQ8Oaf4fyB 8YtN8XC2jCG4fq3mkmuiQuPAbs0lGuFzVBIPHgCdqugpwcl1m/6GoipJWphRT67M UJRWzmxPnR2+mR+EoQ1yRpKqvpNZI38RIC+BPnfbPOHx7Hg9qYtA6orsqXe7Gmul C+Kw5tHsUE4BlWGkZrGKFfT7fpub7ywn2TAOAnThF1S+9DZAJsC

On Thu, Nov 09, 2023 at 11:06:32PM +0100, Hilmar Preuße wrote:

I just noticed that it is not just a display issue on the web page, but a real issue: my latest uploaded was rejected telling me:

Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1, however testing already has version 1.3.8+dfsg-8.
Uploads to unstable must have a higher version than present in testing.

I mean, of course. What were you even expecting...?

Can we override that anyhow?

Even if it was possible, how would that be of any help? You do realize
that versioning order matters for much more than whatever is shown on a
web page, right? Like, apt policy. Or what dpkg does.

I can open an issue at upstream trying to
remove the RfC files, but I guess he's not really interested in these Debian internals. Further it does not solve the issue for this particular upload.

You seem to have skipped the last paragraph of my last email. What
about that?


--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmVNbSMACgkQCBa54Yx2 K62nDxAAm1aHrpggCMWe8jqOA18B4aCJYcWRtP1EwAGXAzz11Y8whJjydEuBbAjq JHGVJFGHyUhUl6xcegUlAkod2SznFJS2ekFfX9qownEyf95J+WqcQ9UO7GB6ezsL mc2agVqZPI1iCr8h+xFyygWSF9xonTQULjKJh0yp1YEa6AuxrNWxWGbwIzjTvOBt AxzgyBeKIZ/fwTusIc0PPHOv4N07xUrNuaKSRZR5KQ7JuAhkb+bgsKVbuJww8Vsk uN/b3FU2BtHXMA8o/E/GAGDnQBJMPvlheRqEK4CDCNXEBC5AkBzdAatWcMvogyyX Bd+KGSig09N+SESf5lUlySl76e8vt9M6hgFAP71l6UN7dliFqVuirF+udf/4okOh /+zqynCgxPHivBeG4gItvKRYdLmZFM8XoDgB23y0cMRlXD/ivpoBwU6fEA1bmgr8 AZ0Mx31kljeR0licJaq32hj0KpVQihWubxA332H60wg55XN5asJMJVBKgmNZg+sm XmB/wOyvxwp+pDN8GMn7VHHaZWP0TnAmle5crmX7S5ipgBarfW4

On 2023-11-09 23:06 +0100, Hilmar Preuße wrote:

On 10/13/23 01:32, Mattia Rizzolo wrote:

On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote:

Hi Mattia,

The upstream minor versions are always determined by letters, so I'm unsure
how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints?

I just noticed that it is not just a display issue on the web page, but a real issue: my latest uploaded was rejected telling me:

Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1, however testing already has version 1.3.8+dfsg-8.
Uploads to unstable must have a higher version than present in testing.

Can we override that anyhow?

No. What's in the archive is in the archive. (Well I think you can ask FTPmasters to remove something but that usually needs a better reason,
like "it contains illegal stuff").

I can open an issue at upstream trying to
remove the RfC files, but I guess he's not really interested in these Debian internals. Further it does not solve the issue for this particular upload.

Right this is a Debian problem not upstream.

I think your options are
1) add an epoch (which exists to deal with this sort of problem)
2) wait till the next (numerical) release 1.3.9 and upload that.
Do releases happen often? This approach only really makes sense
if you/your users can put up with the old version until a higher-versioned one appears
3) upload a 'nobbled' version number, which is often done to deal
with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?

I'd probably go with option 3 in this case. Ugly but temporary.

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmVNkPYACgkQ+4YyUahv nkdIDA//TSoHoBs5doyZbynHiAfySQdOOU8P4K53YZJf4xrN/fyNehM4DBimmOUq c75F3giY5ertLUv1KCbITBTfcHiH8DAuiA3HKitybZA6yF4AEfzDr/PENUykEqLs it+qffH9KjUJ0Q62zhflNQUlFkWeoKPmbisN2DgwX+Gnb0T1s6+yj5iroZe3ZcBK fa8JRwjlBGaVp7Vhh52i6PbUeGU5idHPAWIJS+ak9GWAW2CitUFKSrJUlQ8GoEua aMbsc+0Js5ldythvRVKXWDUed4C/5BOm2I87zJHOoXueE3MkfD32Bgb4DHlZiVss OHiFrahHR3FqASDBwMH/kipBBGAum9pFFjiOHBaOaXbFQ1VvyXdUNvElu2cePccK E9y1JyDlGjAFMSr4NB/doYgYmkVa4/WRhOBI6SmFTuJdFVyWEVu47EdDsCEcUbv5 lY4MyLAbsjYcDPWxRYcI2bdEmcZzDDNI4DD+DA0NpkEDsyBUVnb7DfZNkKCSWePD toJA9KlQBCTah2oSNJpV0LPSSKyv08TQ8yWo97vAk3AlcCaot+Pf+gg8y4dKaD9U 3r7YQs9//l+C74DyUgqs3rF3fCkeAjI57zZHRU2GfFCMp1bOhC/MTgQYkJD2xD8R YbdPiXcmEwe/6LwTleTUhH16ykVL91msPh34qErdKD6cz2jkk0I=
=AU/Q
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote:

On 10.11.2023 03:10, Wookey wrote:

Hi Wookey,

I think your options are
1) add an epoch (which exists to deal with this sort of problem)

Well, would like to avoid it, if possible.

There is no real reason to avoid epochs but they always feel a bit
'ugly' so people do tend to avoid them if they can.

3) upload a 'nobbled' version number, which is often done to deal
with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?

You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b, 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal versioning?

Yes, exactly (sorry my example was a bit confused - I had the 1.3.8
and 1.3.8a ordering backwards in my head, but it doesn't affect the
mechanism). And yes, once you get to 1.3.9 you can go back to normal
version numbering.


Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmVO9M8ACgkQ+4YyUahv nkewUxAAom/VneCZoeCO62WWvMt3ndCQsGPqAuoCYxUJ7kL/MEplM53W6SOZAQfr abEgq+lGbeEbgzDtKKc4MAnqQMi2xtbZ7besKsL48AUjOWGvP3maNxugXBnl5YgK 5Yx2DV4mrRaK0+KBpSXDMaXILEOw90a1mVOJNL6bKutpoivaxZ6cx6E1+ihLIuIJ BfKkfJk+b1mX/ordSIP6kJQ46NUsRcmNHlHMXralJX3xSD/hi8AtV3BvwNYrzEb4 MkSFoQ5dvexN1BjMRMXyy/QKA4jR2E1fYKaqPxNp7a8nMkGM8Q71MP8q1GBCSyWm GIqqCUDglFWGfsRUlx9+BAQRYXQM+aJDi82+mVXDwDmx0DTNC56KR6gOivBc8q/H 5+wr/wUU+2eHXPmNXShEnPFv9Uk0JMZblisiuWKZ+8w6KtYp/p3QdUcBBMAzkxLr MclGZ6pBd8I0GzAov19G7VUCJ3uiOsxfMk1JMrtCzTVT7hNylBZ3j6POj+rxfaHl cQwz3qxYywMw4qJFMDHYp4hXUbVM0P+WomEkQqXWDlaCxtjto9na7Stpg8AyDdWb GR9I5s497edT+2SmIrryFJt5LeB67uXUPTLNlvQvb7ufkSb7SLpe/1PSxMEWOsvA BDWssyySfSFJtDnMoLtKkVcLpbrn/ksTR9gFf81HlenZUtVSRRg=
=E3uE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-11-10 "Preuße, Hilmar" <hille42@web.de> wrote:

On 10.11.2023 03:10, Wookey wrote:

I think your options are
1) add an epoch (which exists to deal with this sort of problem)

Well, would like to avoid it, if possible.

I think it is also not the right solutions, epochs are imho intended to
fix one-off errors, but this is problem recurring with every non-major
release.

[...]

3) upload a 'nobbled' version number, which is often done to deal
with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $? >>

You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b, 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal versioning?

I'd probably go with option 3 in this case. Ugly but temporary.

Sounds like an option for now. Thanks!

I think 1.3.8-a+dfsg-1 would work and you could swith to ~dfsg with
1.3.9 like Mattia suggested:
ametzler@argenau:~$ dpkg --compare-versions '1.3.8+dfsg-8' '<<' 1.3.8-a+dfsg-1 && echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.8-a+dfsg-2 '<<' 1.3.8-b+dfsg-1 && echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.8-b+dfsg-3 '<<' 1.3.9~dfsg-1 && echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.9~dfsg-3 '<<' 1.3.9a~dfsg-1 && echo yes
yes

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Sat, 2023-11-11 at 03:28:21 +0000, Wookey wrote:

On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote:

On 10.11.2023 03:10, Wookey wrote:

I think your options are
1) add an epoch (which exists to deal with this sort of problem)

Well, would like to avoid it, if possible.

There is no real reason to avoid epochs

Oh, but there are! See <https://wiki.debian.org/Teams/Dpkg/FAQ#epochs>.

but they always feel a bit
'ugly' so people do tend to avoid them if they can.

That's the lesser of the issues with epochs. :)

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)