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
Attachment:
signature.asc
Description: signature