Hi Sébastien, Hi Nilesh, I have a bit of time, so am looking up the issue as well. Note that this is not a maneuver I already did, but this is the kind that comes in handy when needed. Sébastien Jodogne, on 2021-06-04: > On 4/06/21 11:45, Nilesh Patra wrote: > > On Fri, 4 Jun, 2021, 2:15 pm Sébastien Jodogne, > > <s.jodogne@orthanc-labs.com <mailto:s.jodogne@orthanc-labs.com>> wrote: > > Adrian (Bunk) replied that "This is fixable with a +really version." > > [...] > > +really is used when version changes aren't consistent, or you need to > > downgrade. > > > > In this case, you would want to downgrade orthanc right? > > To be fair, I am unsure whether I need to downgrade orthanc to 1.9.2, or > to make an additional operation on 1.9.3. At this point of the Debian release, if I were you, I would prefer to revert to the version currently in bullseye, that is currently 1.9.1+dfsg-1 as I can see on the package tracker[0] over bringing more changes on 1.9.3. All changes will be manually reviewed by the release team through a debdiff, so they will be more inclined to let the package migrate to testing if they don't have to dig in a huge patchset. [0] https://tracker.debian.org/pkg/orthanc In the next paragraphs, I assume you want to revert the state in unstable (with v1.9.2) to the state in testing (with v1.9.1). The package version in experimental (v1.9.3) should not interfere; that is the point of experimental. Rereading the discussion, I'm not sure this is entirely clear. > > So you should use this trick only for orthanc to my understanding. > > In the hypothesis that I must downgrade from "orthanc-1.9.3+dfsg-1" to > "orthanc-1.9.2+dfsg-1", should I upload a release with version > "orthanc-1.9.2+really" to unstable? > > Or should I name it "orthanc-1.9.2+dfsg-1-really"? The point of the +really trick is to "erratum" the higher version in unstable by specifying the real version after the marker. Given that the current version in unstable is 1.9.2+dfsg-1, and assuming that you wish to revert in unstable to the state in which your package was in in version 1.9.1+dfsg-1, then the version to upload in order to apply the revert would be: orthanc (1.9.2+really1.9.1+dfsg-1) unstable; ... Subsequent uploads sticking to the content of 1.9.1 release will need to preserve that scheme, e.g. further corrections if deemed necessary before bullseye release, and maintenance of orthanc over bullseye life cycle. You will be able to get back to the normal versionning scheme after the release of bullseye, when uploading orthanc 1.9.3, or greater, into unstable. > In practice, should I first sync my git repository with the tag > "orthanc-1.9.2+dfsg-1", do the modifications and upload to unstable, > then merge back my modifications in the mainline of the git repository, > and finally upload "orthanc-1.9.3+dfsg-2" to experimental? As I understand things, again in the context of a revert from to 1.9.2+dfsg-1 to 1.9.1+dfsg-1, I would probably checkout the 1.9.1+dfsg-1 to get to the state of the package as it was, both regarding the upstream and debian branches, then append in d/changelog the unmodified content of the 1.9.2+dfsg-1 upload and the entry for 1.9.2+really1.9.1+dfsg-1, which should only indicate the revert of the package to the state it was in in version 1.9.1+dfsg-1, and tag debian/1.9.2+really1.9.1+dfsg-1. The resulting debdiff between orthanc_1.9.1+dfsg-1.dsc and orthanc_1.9.2+really1.9.1+dfsg-1.dsc should, ideally, only show the added entries in the changelog. Note I may not have the best git skills in the world, it just sounds like the simplest approach to me. > > Also note that it is unclear to me what exact package should be put in > > "Built-Using". Is it "src:orthanc", "liborthancframework1", or > > "liborthancframework-dev", > > > > > > All libraries that you have statically linked against. See the binary > > packages that are relevant/contain the files that are being used for linking > > > > with or without version? > > > > > > With version, and more specifically with an exactly = relation. > > Please see the Debian Developers reference wherein it's clearly explained. > > From what I see in the Debian Developers reference [1], and from your > explanations, I guess I should use: > > Built-Using: liborthancframework-dev (= 1.9.2+really) I've been digging into the policy as well and read that: the Built-Using field must list the corresponding source package for any affected binary package incorporated during the build, including an “exactly equal” (“=”) version relation on the version that was used to build that version of the incorporating binary package. In which case, it is the src:orthanc which needs to be listed. So I would apply the following field to address bugs #989126, #989127, #989128: Built-Using: orthanc (= 1.9.2+really1.9.1+dfsg-1) That would work, but after upload of said version of orthanc 1.9.2+really1.9.1+dfsg-1 into unstable first. > Thanks again, > Sébastien- > > [1] https://www.debian.org/doc/debian-policy/ch-relationships.html I just saw Nilesh's answer, so it seems we have converging opinions on the 1.9.2+really1.9.1+dfsg-1 version :) although I may have a different view on the package name to specify to the Built-Using. I'm sorry for the present confusion, and I hope I have been able to clarify things. In any case, Many Thanks for your huge work on orthanc, both as upstream and debian maintainer! Hope this helps, -- Étienne Mollier <etienne.mollier@mailoo.org> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
Attachment:
signature.asc
Description: PGP signature