On 04/06/21 06:37 PM, Sébastien Jodogne wrote: > Dear Nilesh, > > Thank you very much for your help! > > > On 4/06/21 11:45, Nilesh Patra wrote: > > Hi Sébastien > > > > 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. > I think we aren't on the same page here. 1.9.3 is experimental right? It doesn't have anything to do here.I'll re-iterate the problem so we are absolutely sure of the things here, fair? * Experimental is not in the picture here, so I guess we will kick this out of the equation here * There's orthanc-* (orathnc-wsi, orthanc-imagej et. al.) packages have now started linking statically, and you need to use a Built-Using field as doko said in the bug report. * Now, what you could've done is simply add this field and upload. But there's a problem - what is that? You uploaded a new version of orthanc i.e. 1.9.2 to *unstable* * Alright, but what is the problem? - The problem is that now when you add such a field and upload, this will link against the orthanc 1.9.2 in unstable. And 1.9.2 of orthanc will not enter testing at this stage - reason being we are in deep freeze and this is far beyond the acceptable limit. * So you basically need to devise a way for orthanc-* (wsi, imagej etc. etc.) to link against orthanc (1.9.1) in "testing". And doing this is hard! If however you find a way to do this, doing this might be cheaper. But admittedly, such a way does not strike me directly. * So what you can do is, simply downgrade orthanc to "1.9.1" i.e. the version in "testing", ask the release team to allow this downgraded version to migrate to testing. Now when it is there, simply upload the orthanc-* with "Built-Using" field added. Now downgrading is not too simple - a discussion about which is done below. > > 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? Nopes. The next versions should be greater than the already existing ones.For instance, you cannot upload a version, say "x" and then upload "x-1" - it'll be rejected. Versions must increase progressively. And 1.9.2+really < 1.9.3+dfsg-1 $ dpkg --compare-versions 1.9.3+dfsg-1 gt 1.9.2+really $ echo $? 0 > Or should I name it "orthanc-1.9.2+dfsg-1-really"? > > 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? Hmm. Let me explain it a bit so we are on the same page. Full picture: Suppose an upstream uses 1.1 of a certain package and then some stuff happens, and they decide tore-label versions. So the next version it releases is say 1.0 Some upstreams do not follow semantic versioning properly and have weird release naming. So in the case I mentioned, let's say the package maintainer has uploaded 1.1 and realises that there's an inconsistency. So the +really does the job here. The maintainer would upload "1.1+really1.0" which basically means that the version actually is 1.0 1.1+really1.0 > 1.0-foo right? Now in our particular case, the upstream is doing an alright job, no inconsistency but you uploaded a new version that messed things up. So the idea is to use this trickhere as well. We need <new-version>+really<old-version> for example see node-graphlibrary[2] i.e. see the version number. However, in this scenario, we will do this trick to do a "1.9.2+really1.9.1+dfsg-1" Upload, because: 1.9.2+really1.9.1+dfsg-1 > 1.9.2+dfsg-1 $ dpkg --compare-versions 1.9.2+really1.9.1+dfsg-1 gt 1.9.2+dfsg-1 $ echo $? 0 And **after** bullseye is released, version 1.9.3+dfsg-1 can be uploaded to *unstable*, since the latter is greater than the +really one $ dpkg --compare-versions 1.9.3+dfsg-1 gt 1.9.2+really1.9.1+dfsg-1 $ echo $? 0 Please do let me know if you have any sort of confusion now. > > 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 *think* (=1.9.2+really1.9.1+dfsg-1) But in any case, before uploading *anything* please coordinate your work with the release team - tell them clearly what exactly you intend to do, and get a pre-ACK from them. Just file a bug against release.d.o package and see the responses, do accordingly. and maybe ask bunk (Adrian) for review too - bunk is really nice, and is doing a great job and I'm sure he'll help. > [1] https://www.debian.org/doc/debian-policy/ch-relationships.html [2]: https://tracker.debian.org/pkg/node-graphlibrary Nilesh
Attachment:
signature.asc
Description: PGP signature