On Wed, 2022-10-19 at 23:04 -0700, Debora Velarde Babb wrote:

Initially I attempted to create the package with the new name ibmtss.
There was some discussion on debian-mentors list and the response was
that I should NOT change the name to ibmtss and instructed to instead
use an epoch number.

Personally I would rename the package to ibmtss. Renaming represents
one-time migration pain for yourself, the Debian ftp-masters and all of
the existing package users, but not renaming represents confusion for
every person looking for the new upstream name but not finding it in
Debian if we didn't follow the upstream renaming, potentially this
could even lead to someone packaging it as ibmtss too.

--
bye,
pabs

https://wiki.debian.org/PaulWise

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

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmNRAAUACgkQMRa6Xp/6 aaMV1hAAg56F1Mv9jW+MNIIq89BqZQN/SU95lpUdn09uBfszh/U/c9PdLNJ4Fi2M iP60oRAN69V4Nx4MY08nb4UUdIsfa4NxMgn7qGpBagrZ0asDr7WhSOt1vISDTdXi IHmdkhSqHxEpi/MFxQRwb8nVQ4RI2/8iHG77AOU0Y/uxJuFKWuM+1e/wGn0jqBG9 064YRwsxoqxZp6lSmTCWdPBsfbfb/7SS4ZHXu9rLs//S5tKD+W7pq94rC97gASXF QFnqsFEK1GwVtsiuCDRB7ZbasZKBATwHawG6mt6kWvghCI8vG0xI8A4nWTM3vjPp +WZ7QfrTHMHELsYz6g1Uc0fHgElbF1EMUh/RzrAoexKyecpaNFAkRz8WM6BCJje9 H2zyiySX0kTr/Q8jrzzJRHQp1lAUchPnaAc4/y6LAtYeXNshImABBIxIJsOVVD+v G8vWNd1f+Uvbst4p5apeEU1MAYMOEENVl4dl4nhf2r5wVkW4y77IEoKy6+1MRj8f hTSaGKlsFyKyfdfjCTWQ4Ly+VQtSUrgRxE29N/ILg5LruNFj7XvNB3bgucyXG1K1 Co5QRpD3MAW3oKX4jgXex3JcFHThuv/aFSFGa6iQ6wf4CI3ebVaMR93KBWJKelyH SB1hqBn+fiWx3xbYOp3wV0jy4O1Ge5t9GVUU3rf2MZ3Nole3eVI=
=9A7Z
-----END PGP SIGNATURE-----

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

Greetings,

The upstream package for tss2 has been renamed ibmtss. When the name
was changed upstream, the version number convention also changed.
Upstream tss2-1470 was updated to ibmtss-1.3.0. The current version of
ibmtss is now 1.6.0. I believe I need to use an epoch number to handle
the version change correctly.

Initially I attempted to create the package with the new name ibmtss.
There was some discussion on debian-mentors list and the response was
that I should NOT change the name to ibmtss and instructed to instead
use an epoch number.

I recently posted a packaging question to the debian-mentors list and
someone kindly explained that use of an epoch number needed to be
discussed on debian-devel first.

Thank you,
Debora Babb

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

Hi Debora,

Quoting Debora Velarde Babb (2022-10-20 08:04:35)

The upstream package for tss2 has been renamed ibmtss. When the name was changed upstream, the version number convention also changed. Upstream tss2-1470 was updated to ibmtss-1.3.0. The current version of ibmtss is now 1.6.0. I believe I need to use an epoch number to handle the version change correctly.

Initially I attempted to create the package with the new name ibmtss.
There was some discussion on debian-mentors list and the response was
that I should NOT change the name to ibmtss and instructed to instead
use an epoch number.

which discussion was that? I searched the last four months of the debian-mentors list archive for your name as well as for the string "tss" and couldn't find the advice to use an epoch instead renaming the source package. Just like pabs (and for the same reason) I would argue for a one-time migration rather than carrying a wrong name as well as the epoch number forever.

I recently posted a packaging question to the debian-mentors list and someone kindly explained that use of an epoch number needed to be discussed on debian-devel first.

That is correct. Thanks for reaching out to us! :)

cheers, josch
--==============06099145369073829=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmNRAp8ACgkQ8sulx4+9 g+EqcQ/+NCZfPK7b5qxnoLNimJ+D3L58h56+lZZ+mwcUGfYktPFp9s9P32pnBLBt mmTFBPft0EztbJceovl5CiRUdsV2WQ2H1qFZ/LSNSDgzQ56tOlpX68SAGIh126yW EjyHIYObIthitrtmfAJHm+X/9MRovzN8Wc4/yxAqkdSr/JSkxSrOl76b8YjsUSnD Y5y+LGR/Dq/+PSncOslBzQ3HvgxsFouTaRfm2ObB1cjj7LjfI6zZWahNpysbUXXW YImFBQ7XpyPkxYif3eg56fcAOiPl34AhYAEmfrdvKXO02ImJZgc+T6yZTFcbpvV0 ggL3ahTkgcgiUfhXi56vsrGuNGk3UQvaPcAQGlOKFNeiInwFX+8H5mz0JcW9i5ML JvNReQ+jRmcgGh8CWw5c/9+WCht/fYwbTmcwt7FtX+D74FVdGd0xcBaffzjFCznT OrRNvlh2iKh/W/kAjsFVv75H0ZgZNmG+f0nqQGTm0CWZm8hQY3F/938NNKTXoXY+ NOKCUKcdWUgHaXZYvRtNPGA2UgxhhOYlqc3+Nn6pPhpE3hxaHXUlR9G4sa+EhIBz +khBF1h5a/4zir95e6uz+ZFFpZ4MvDbEQ5jpt7cgpAXNsMxrFnfv5Mzdkrpfa+cN pZp6At02hfLnXZvI5zvO2qcIXMoiWfgPey2uB6zqDnmdzDi2WdE=
=zFf/
-----END PGP SIGNATURE-----

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

Hello Debora Babb,

On Wed, Oct 19, 2022 at 11:04:35PM -0700, Debora Velarde Babb wrote:

Greetings,

The upstream package for tss2 has been renamed ibmtss. When the name
was changed upstream, the version number convention also changed.
Upstream tss2-1470 was updated to ibmtss-1.3.0. The current version of ibmtss is now 1.6.0. I believe I need to use an epoch number to handle
the version change correctly.

Upstream renaming their project is one of the very few chances you get
to GET RID OF an epoch in a debian package!

Initially I attempted to create the package with the new name ibmtss.
There was some discussion on debian-mentors list and the response was
that I should NOT change the name to ibmtss and instructed to instead
use an epoch number.

This seems like very bad advice to me.

IMHO you should:

1. package the new project under the new name.
(i.e. rename both source and binary packages.)
2. Provide additional empty binary (transitional) packages under the old
name which depends on the respective new binary packages, so old
installations gets upgraded to the new package.
3. Use a debian/rules override to alter version number *only* for the
empty transitional packages, so that they get a higher version number
than was previously provided. eg. last-tss2-version+really1.3.0-1


eg.

override_dh_gencontrol:
# Make transitional packages have a higher version number
# than the old binary packages built from src:tss2 (1045-1.2)
dh_gencontrol --package=tss2 -- \
-v1045+really1.6.0-1
dh_gencontrol --package=libtss0 -- \
-v1045+really1.6.0-1
dh_gencontrol --package=libtss-dev -- \
-v1045+really1.6.0-1
# Use the correct version number for real binary packages
dh_gencontrol --remaining-packages


Once your transitional packages has shipped in a stable release,
you can then remove them from debian/control and also drop the
debian/rules override of dh_gencontrol in your next upload to unstable.

I recently posted a packaging question to the debian-mentors list and
someone kindly explained that use of an epoch number needed to be
discussed on debian-devel first.

That's correct and the reason is to avoid unneccesarily introducing
epochs since they are so hard to get rid of (and confuse alot of users).

Thank you,
Debora Babb

Regards,
Andreas Henriksson

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

Quoting Andreas Henriksson (2022-10-20 12:13:24)

Hello Debora Babb,

On Wed, Oct 19, 2022 at 11:04:35PM -0700, Debora Velarde Babb wrote:

Greetings,

The upstream package for tss2 has been renamed ibmtss. When the name
was changed upstream, the version number convention also changed.
Upstream tss2-1470 was updated to ibmtss-1.3.0. The current version of ibmtss is now 1.6.0. I believe I need to use an epoch number to handle
the version change correctly.

Upstream renaming their project is one of the very few chances you get
to GET RID OF an epoch in a debian package!

Initially I attempted to create the package with the new name ibmtss. There was some discussion on debian-mentors list and the response was
that I should NOT change the name to ibmtss and instructed to instead
use an epoch number.

This seems like very bad advice to me.

IMHO you should:

1. package the new project under the new name.
(i.e. rename both source and binary packages.)
2. Provide additional empty binary (transitional) packages under the old
name which depends on the respective new binary packages, so old
installations gets upgraded to the new package.
3. Use a debian/rules override to alter version number *only* for the
empty transitional packages, so that they get a higher version number
than was previously provided. eg. last-tss2-version+really1.3.0-1

eg.

override_dh_gencontrol:
# Make transitional packages have a higher version number
# than the old binary packages built from src:tss2 (1045-1.2)
dh_gencontrol --package=tss2 -- \
-v1045+really1.6.0-1
dh_gencontrol --package=libtss0 -- \
-v1045+really1.6.0-1
dh_gencontrol --package=libtss-dev -- \
-v1045+really1.6.0-1
# Use the correct version number for real binary packages
dh_gencontrol --remaining-packages

Once your transitional packages has shipped in a stable release,
you can then remove them from debian/control and also drop the
debian/rules override of dh_gencontrol in your next upload to unstable.

The transitional package should be Priority:optional and Section:oldlibs according to devref 6.8.7.:

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#make-transition-packages-deborphan-compliant

What is the reason for using a transitional package instead of using Provides/Conflicts/Replaces? I found

https://wiki.debian.org/RenamingPackages

But that lists:

Cannot be used for packages that are used in build dependencies, as several build tools (like sbuild) do not support virtual packages in those dependencies by design, to guarantee deterministic builds.

Wait what? If sbuild doesn't support virtual packages I'd like to hear about that. Can I just remove this reason from the wiki page? It is obviously wrong. If it is not, please file a bug against sbuild.

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?

Thanks!

cheers, josch
--==============G43541988603825337=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmNRM8UACgkQ8sulx4+9 g+H3VQ/+JzvP0SA6Nwrv0ittwZ6ayWRqgJdsxYBklcHVYfcB+CXXV3BvhOIj8Yk3 kq+LKEEbmP2KOTzURe8SfYIgy8h2ql3WnE1lq/pN2AjuuRnZfy4sjo1W9DptIPrU nRZ79SyoQUzwAm6AEKuE1qqcQtoABoogqIFjJAiYaH6ViH0VJyKKpQUe66ynnv4v kH/UGN06A3yZnvFto4/DNNJ8ges9Xc8We9WZ5pJMIC4qvTpmaTPQL8ofcSA76HcD SJoufpkmrIc9yQs64MmFBXzs9lF4uqr6qPL1oOUeOHSax8hfQcgXcTAWa9JOYvpd CAlkHATL5VZGx+qjcwUjmbMT+2kALoOFE9AKAELCMco4wYeaFI6Tm/2ywj74kjjW JOJwdKzRgK4gWVf4gnCNUJHc8yUhYuTWk2Y8nd14NVjUJsjdLt0ozIoK9PP6KWjp qPUtOV0Ws5M4/ejfE3ubidaKI9DyXjiDXpzKfRR1dc+eCTV5JbSXswg92i0Ci38J DPKLUhkkMvHsUOYJDF10YIkLGF5Cndl9/RyyP2zl+7cU409MFkRitg72iWYkolLl stmFxea5GV5UcT6PWDDmIEx+DysM33H9Lg04brBkb6UFh8dhlubOS7OrR58k19JF mWr1lCX53ahV199fhmEs64lrXFlGCD30V6pDm/PXCajC9RCi39E=
=m8t4
-----END PGP SIGNATURE-----

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

On 20.10.22 13:40, Johannes Schauer Marin Rodrigues wrote:

Quoting Andreas Henriksson (2022-10-20 12:13:24)

Cannot be used for packages that are used in build dependencies, as several >> build tools (like sbuild) do not support virtual packages in those
dependencies by design, to guarantee deterministic builds.

Wait what? If sbuild doesn't support virtual packages I'd like to hear about that. Can I just remove this reason from the wiki page? It is obviously wrong.
If it is not, please file a bug against sbuild.

The correct statement here is that you ought to pick a default choice
first[1] before a virtual alternative. We don't want to leave it up to
the resolver to pick an arbitrary available build-dependency. So this is
more of a policy rather than a technical question. Behavior for
experimental might currently differ due to a different resolver choice
that's more flexible by design - to get newer versions from experimental
if necessary.

Kind regards
Philipp Kern

[1] This might require an overall agreement across Debian at times. But
that seems to be more relevant for dependencies than build-dependencies.

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

Quoting Philipp Kern (2022-10-20 14:29:13)

On 20.10.22 13:40, Johannes Schauer Marin Rodrigues wrote:

Quoting Andreas Henriksson (2022-10-20 12:13:24)

Cannot be used for packages that are used in build dependencies, as several
build tools (like sbuild) do not support virtual packages in those
dependencies by design, to guarantee deterministic builds.

Wait what? If sbuild doesn't support virtual packages I'd like to hear about
that. Can I just remove this reason from the wiki page? It is obviously wrong.
If it is not, please file a bug against sbuild.

The correct statement here is that you ought to pick a default choice first[1] before a virtual alternative. We don't want to leave it up to
the resolver to pick an arbitrary available build-dependency. So this is
more of a policy rather than a technical question. Behavior for
experimental might currently differ due to a different resolver choice that's more flexible by design - to get newer versions from experimental
if necessary.

Kind regards
Philipp Kern

[1] This might require an overall agreement across Debian at times. But that seems to be more relevant for dependencies than build-dependencies.

Is that really the correct statement? Even after excluding all virtual packages with a single provider, there are literally thousands of source packages for which their first alternative is a virtual package. Is this "policy" documented somewhere? Because if it is, then it either should change or the archive has to be changed to match that policy.

In any case, this was not my original question. Andreas presented a way to use a transitional package to rename a package which will work fine I guess except that we have to carry an empty package for a release and that empty package has to be cleaned up at some point, for example by deborphan.

My original question was why using a virtual package for the same purpose is a bad idea. The wiki page https://wiki.debian.org/RenamingPackages lists reasons against it that are incorrect. So why is it really a bad idea?

Is there any reason not to delete the first reason (the sbuild one) completely?

And either I misunderstand the second reason or I implemented my POC incorrectly or apt (as of 2022-10-21) is perfectly capable of replacing the old with the new one.

Can somebody shed some light on this?

Thanks!

cheers, josch
--==============(03224818133287708=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmNS344ACgkQ8sulx4+9 g+EMvw/9FvpTrq8Qm3xUeO/f3flLQKKn0RuS+8j2+l8Hdcgf7xMgRH8nyLSIX0na t033U72Qb+yNWqvraah0JdWx0nl+wrC2J8l8dmWWlkWkxuHyGq/987/nNOg0Cnvk yDqGHWZO3O5DsY6fdD8zoRmx716IdolMFpz1lXD4F+n5lK+oYbAmH4iXcT2HE6s0 pfPGLGaV1vpOqKlo5V86Q49RqnCJn1gGoByreE9damnM9KU82Z0x2R2xLCG4vV/0 GLk2B2ti3CQ/Mb1Ya06VkbUVc84z4LaoJQ4Be17pmcy/C1dWX+2NJe36oqKtBv/v /jT6SvUnvuRhrGO2EHBZxBspbyGSQFin/P3nkhZtwgWQ1GiZYumXeByyD6CREAKW is2anjFoFdHzVhRD3+kiSQ7OraMb97n+bx71vBq5fRHFIrjmYXJlyjWe/ozDAwfb ST8yA+uYWTOmES+YZRY5ZRKrwlMaugBp/mJxcDa6RYszQlcM60fyQwLhwpglR8Cy utkkpFd2rnDGmUzcj+cLhUgI3c+D/jn8uYJqgkuXmC34IAjZdiM3Ep1RAU1ky0ap 4DmiOkTT5/uSU0npzqKMRWkl8vitFP9gaFBvN3bUHOfQek0fJSvCkasmMMjZJMsl qXrKKbfJLLrNg0VzcDgiQ0O7etu2KCsC9dY/NFaybjZmYi+BofY=
=Uxfo
-----END PGP SIGNATURE-----

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

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

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

On 21.10.22 20:06, Johannes Schauer Marin Rodrigues wrote:

Is that really the correct statement? Even after excluding all virtual packages
with a single provider, there are literally thousands of source packages for which their first alternative is a virtual package. Is this "policy" documented
somewhere? Because if it is, then it either should change or the archive has to
be changed to match that policy.

Hm, good point. I thought it was documented in a way stronger way than
it actually is. In [1] it says:

To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one.

Which does not say that you have to, only what you should do if you want
to specify a real package.

In any case, this was not my original question. Andreas presented a way to use
a transitional package to rename a package which will work fine I guess except
that we have to carry an empty package for a release and that empty package has
to be cleaned up at some point, for example by deborphan.

My original question was why using a virtual package for the same purpose is a
bad idea. The wiki page https://wiki.debian.org/RenamingPackages lists reasons
against it that are incorrect. So why is it really a bad idea?

Is there any reason not to delete the first reason (the sbuild one) completely?

And either I misunderstand the second reason or I implemented my POC incorrectly or apt (as of 2022-10-21) is perfectly capable of replacing the old
with the new one.

Can somebody shed some light on this?

Yeah, I think that line should be deleted as it might never have been
true. I checked the first code in git from 2004 and it doesn't reject
virtual packages either. It does pick a winner manually in the resolver
and it looks random (or rather in "apt showpkg" order). But it's not
like it didn't work.

Kind regards
Philipp Kern

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

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

On Thu, 2022-10-20 at 10:11 +0200, Johannes Schauer Marin Rodrigues
wrote:

Hi Debora,

Quoting Debora Velarde Babb (2022-10-20 08:04:35)

The upstream package for tss2 has been renamed ibmtss. When the
name was
changed upstream, the version number convention also
changed. Upstream
tss2-1470 was updated to ibmtss-1.3.0. The current version of
ibmtss is now
1.6.0. I believe I need to use an epoch number to handle the
version change
correctly.

Initially I attempted to create the package with the new name
ibmtss.
There was some discussion on debian-mentors list and the response
was
that I should NOT change the name to ibmtss and instructed to
instead
use an epoch number.

which discussion was that? I searched the last four months of the debian-mentors list archive for your name as well as for the string
"tss" and
couldn't find the advice to use an epoch instead renaming the source
package.

Apologies, I was incorrect, I did not get that advice from debian-
mentors list. I had opened a request to salvage the tss2 package and
take over as maintainer. That lead to some discussions between myself
and two other debian developers via direct messages. So the discussion
was not included in a mailing list.

Just like pabs (and for the same reason) I would argue for a one-time migration
rather than carrying a wrong name as well as the epoch number
forever.

I recently posted a packaging question to the debian-mentors list
and someone
kindly explained that use of an epoch number needed to be discussed
on
debian-devel first.

That is correct. Thanks for reaching out to us! :)

cheers, josch

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