Re: epoch for tss2 package

[Simon McVittie <smcv@debian.org>]

On Thu, 20 Oct 2022 at 13:40:56 +0200, Johannes Schauer Marin Rodrigues wrote:
> > Most package managers (including APT, as of 2011-02-21) do not know to
> > replace the old with the new one and will only use the new package if it is
> > installed for some other reason.
> 
> That is a rather old timestamp. And I also do not understand what the author
> tries to say here. Isn't using the new package exactly what we want here?

I think you might be parsing the sentence as:

    apt will (only use the new package) etc.

and thinking "great, apt will exclusively use the new package, my work here
is done!", but the intended parsing is:

    apt will only (use the new package)
    if ([the new package] is [going to be] installed for some other reason)

In other words, if the state of the system is:

    oldname version 20200102 is installed
    newname version 2.0 is available
    newname Provides, Breaks, Replaces: oldname
    some-related-package is installed
    some-related-package Depends: oldname

then the assertion (which I haven't verified) is that `apt upgrade`
has no particular reason to want to install newname, and will therefore
keep oldname instead, unless there happens to be an additional dependency
that specifically pulls in newname:

    oldname version 20200102 is installed
    newname version 2.0 is available
    newname Provides, Breaks, Replaces: oldname
    some-related-package version 1 is installed
    some-related-package version 2 is available
    some-related-package version 2 Depends: newname

at which point upgrading some-related-package to version 2 should make
apt realise that newname is needed, at which point the Breaks/Replaces
will clean up oldname, and the Provides will avoid breaking anyone else's
dependencies.

With a transitional package, it's obvious (both to apt and to a developer
trying to understand what is going on) that the intention is for an
upgrade from oldname 20200102 to oldname 1:2.0 (or 20221021+really2.0 or
however you prefer to spell it) to force newname to be installed, even
if nothing else on the system refers to the library by its new name yet.

I think there were examples during the bullseye cycle of maintainers
trying to avoid needing a transitional package, doing what you're now
advocating, finding that it didn't actually upgrade systems correctly,
and having to add a transitional package anyway - but I can't remember
specific package names and versions, sorry.

    smcv