Re: epoch for tss2 package
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
Re: epoch for tss2 package
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
Re: epoch for tss2 package
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
Re: epoch for tss2 package
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 signature.asc Description: signature
Re: epoch for tss2 package
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.
Re: epoch for tss2 package
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 signature.asc Description: signature
Re: epoch for tss2 package
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
Re: epoch for tss2 package
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 signature.asc Description: signature
Re: epoch for tss2 package
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 signature.asc Description: This is a digitally signed message part
epoch for tss2 package
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
