Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Em quinta-feira, 22 de junho de 2023, Adrian Bunk escreveu: > On Tue, Jun 20, 2023 at 11:12:58PM -0300, Eriberto wrote: > > Hi Adrian, > > Hi Eriberto, > > > Em ter., 20 de jun. de 2023 às 18:18, Adrian Bunk > escreveu: > >... > > > A shared library package libjodycode2 provides the shared library > > > libjodycode.so.2, and not providing it breaks reverse dependencies. > > > > > > libjodycode2 must either provide libjodycode.so.2 by shipping it > > > or depending on a package that does ship it, or libjodycode2 must > > > be dropped. Anything other than dropping it would be highly unusual. > > > > > > In at the moment, only jdupes depends of the libjodycode"X" on Debian, > > so I think that libjodycode2 (transitional) must be dropped, right? > > (jdupes 1.24 was replaced by jdupes 1.25, that depends of the > > libjodycode3). > > A transitional libjodycode2 shouldn't ever have existed since it causes > breakage of reverse dependencies (in this case only jdupes). > > Never having libjodycode2 would also automatically make it an > auto- transition at [1] showing what packages need rebuilding. Thanks for the clarification. Your words are very useful for my to learn a bit more about libs. > > > A transitional package libjodycode2-dev would be possible, > > > but there is no real benefit for a just created package. > > > > > > The -dev package should be named libjodycode-dev, > > > which is a stable name. > > > > What is the right way to make this? Renaming to libjodycode-dev, > > dropping libjodycode3-dev and sending again to NEW? Should I use > > Breaks and Replaces to make a reference to libjodycode3-dev? > > Sounds like a good plan to me. Thanks! Package already in NEW. Eriberto > > Thanks for your attention. > > > > Cheers, > > > > Eriberto > > cu > Adrian > > [1] https://release.debian.org/transitions/ >
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
On Tue, Jun 20, 2023 at 11:12:58PM -0300, Eriberto wrote: > Hi Adrian, Hi Eriberto, > Em ter., 20 de jun. de 2023 às 18:18, Adrian Bunk escreveu: >... > > A shared library package libjodycode2 provides the shared library > > libjodycode.so.2, and not providing it breaks reverse dependencies. > > > > libjodycode2 must either provide libjodycode.so.2 by shipping it > > or depending on a package that does ship it, or libjodycode2 must > > be dropped. Anything other than dropping it would be highly unusual. > > > In at the moment, only jdupes depends of the libjodycode"X" on Debian, > so I think that libjodycode2 (transitional) must be dropped, right? > (jdupes 1.24 was replaced by jdupes 1.25, that depends of the > libjodycode3). A transitional libjodycode2 shouldn't ever have existed since it causes breakage of reverse dependencies (in this case only jdupes). Never having libjodycode2 would also automatically make it an auto- transition at [1] showing what packages need rebuilding. > > A transitional package libjodycode2-dev would be possible, > > but there is no real benefit for a just created package. > > > > The -dev package should be named libjodycode-dev, > > which is a stable name. > > What is the right way to make this? Renaming to libjodycode-dev, > dropping libjodycode3-dev and sending again to NEW? Should I use > Breaks and Replaces to make a reference to libjodycode3-dev? Sounds like a good plan to me. > Thanks for your attention. > > Cheers, > > Eriberto cu Adrian [1] https://release.debian.org/transitions/
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Em qua., 21 de jun. de 2023 às 23:58, Jody Bruchon escreveu: > > Thanks for all that information! While I'm here, I should also point out > that another Debian package will eventually have to adopt libjodycode as > well: winregfs [1]. Fortunately it doesn't use any of the APIs that > changed between libjodycode 2 and 3 so changing what it needs to link to > is as simple as recompiling and pointing it to the correct libjodycode.h > header. > > [1] https://packages.debian.org/sid/utils/winregfs Thanks again Jody. The winregfs is maintained by my close friend Giovani. I am ending the revision libjodycode_3.0.1-3. > On 2023-06-21 10:14 PM, Eriberto wrote: > > Hi Jody! > > > > Em qua., 21 de jun. de 2023 às 21:09, Tritech - Jody > > escreveu: > >> Hi! I'm upstream. Would it be helpful if I provided a way to build a > >> compatibility shim libjodycode.so.2 with the old API 2 interfaces that > >> translates and links to the API 3 version? I'd be happy to provide that if > >> desired. > > I think this is not needed because all these new packages don't > > arrived to Debian Testing yet. The jdupes 1.25.0 already killed the > > 1.24.0, so libjodycode2 is no longer useful for Debian. I will follow > > the changes purposed by Adrian. I will start changing the packaging of > > the lib. Furthermore, I was wrong when making a -dev package with > > soname number attached. It was a mistake. The changes will make the > > lib arrives to NEW queue again. > > > > Thanks a lot Adrian and Jody. > > > > Cheers, > > > > Eriberto >
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Thanks for all that information! While I'm here, I should also point out that another Debian package will eventually have to adopt libjodycode as well: winregfs [1]. Fortunately it doesn't use any of the APIs that changed between libjodycode 2 and 3 so changing what it needs to link to is as simple as recompiling and pointing it to the correct libjodycode.h header. [1] https://packages.debian.org/sid/utils/winregfs On 2023-06-21 10:14 PM, Eriberto wrote: Hi Jody! Em qua., 21 de jun. de 2023 às 21:09, Tritech - Jody escreveu: Hi! I'm upstream. Would it be helpful if I provided a way to build a compatibility shim libjodycode.so.2 with the old API 2 interfaces that translates and links to the API 3 version? I'd be happy to provide that if desired. I think this is not needed because all these new packages don't arrived to Debian Testing yet. The jdupes 1.25.0 already killed the 1.24.0, so libjodycode2 is no longer useful for Debian. I will follow the changes purposed by Adrian. I will start changing the packaging of the lib. Furthermore, I was wrong when making a -dev package with soname number attached. It was a mistake. The changes will make the lib arrives to NEW queue again. Thanks a lot Adrian and Jody. Cheers, Eriberto
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Hi Jody! Em qua., 21 de jun. de 2023 às 21:09, Tritech - Jody escreveu: > > Hi! I'm upstream. Would it be helpful if I provided a way to build a > compatibility shim libjodycode.so.2 with the old API 2 interfaces that > translates and links to the API 3 version? I'd be happy to provide that if > desired. I think this is not needed because all these new packages don't arrived to Debian Testing yet. The jdupes 1.25.0 already killed the 1.24.0, so libjodycode2 is no longer useful for Debian. I will follow the changes purposed by Adrian. I will start changing the packaging of the lib. Furthermore, I was wrong when making a -dev package with soname number attached. It was a mistake. The changes will make the lib arrives to NEW queue again. Thanks a lot Adrian and Jody. Cheers, Eriberto
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Hi! I'm upstream. Would it be helpful if I provided a way to build a compatibility shim libjodycode.so.2 with the old API 2 interfaces that translates and links to the API 3 version? I'd be happy to provide that if desired. Jody Bruchon
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Apologies, I sent my last email from the wrong account. j...@jodybruchon.com is the correct account if replying directly. Thanks! On June 21, 2023 7:54:54 PM EDT, Tritech - Jody wrote:
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Hi Adrian, Initially, thanks for your help. Em ter., 20 de jun. de 2023 às 18:18, Adrian Bunk escreveu: > > Package: libjodycode2 > Version: 3.0.1-1 > Severity: serious > Tags: ftbfs > Control: affects -1 src:phcpack jdupes > > https://buildd.debian.org/status/fetch.php?pkg=phcpack=amd64=2.4.86%2Bdfsg-5=1687282110=0 > > ... > jdupes -l src/Python/PHCpy3/doc/build/html/_images/math > jdupes: error while loading shared libraries: libjodycode.so.2: cannot open > shared object file: No such file or directory > make[1]: *** [debian/rules:44: override_dh_auto_build-arch] Error 127 I packaged this lib after the freeze and I sent it to NEW queue in June, 13. The package was approved in June, 15. However, the upstream dropped the libjodycode2 in June, 16, releasing libjodycode3. The jdupes in stable don't depend on a lib. jdupes 1.24 depends on the libjodycode2 and the new jdupes 1.25 depends on the libjodycode3. I uploaded libjodycode3 to unstable this morning, but jdupes was 1.24, depending on the libjdupes2. Some hours after this, I uploaded jdupes 1.25. > A shared library package libjodycode2 provides the shared library > libjodycode.so.2, and not providing it breaks reverse dependencies. > > libjodycode2 must either provide libjodycode.so.2 by shipping it > or depending on a package that does ship it, or libjodycode2 must > be dropped. Anything other than dropping it would be highly unusual. In at the moment, only jdupes depends of the libjodycode"X" on Debian, so I think that libjodycode2 (transitional) must be dropped, right? (jdupes 1.24 was replaced by jdupes 1.25, that depends of the libjodycode3). > A transitional package libjodycode2-dev would be possible, > but there is no real benefit for a just created package. > > The -dev package should be named libjodycode-dev, > which is a stable name. What is the right way to make this? Renaming to libjodycode-dev, dropping libjodycode3-dev and sending again to NEW? Should I use Breaks and Replaces to make a reference to libjodycode3-dev? Thanks for your attention. Cheers, Eriberto
Bug#1038752: libjodycode2: A shared library package cannot be a transitional package on a different soversion
Package: libjodycode2 Version: 3.0.1-1 Severity: serious Tags: ftbfs Control: affects -1 src:phcpack jdupes https://buildd.debian.org/status/fetch.php?pkg=phcpack=amd64=2.4.86%2Bdfsg-5=1687282110=0 ... jdupes -l src/Python/PHCpy3/doc/build/html/_images/math jdupes: error while loading shared libraries: libjodycode.so.2: cannot open shared object file: No such file or directory make[1]: *** [debian/rules:44: override_dh_auto_build-arch] Error 127 A shared library package libjodycode2 provides the shared library libjodycode.so.2, and not providing it breaks reverse dependencies. libjodycode2 must either provide libjodycode.so.2 by shipping it or depending on a package that does ship it, or libjodycode2 must be dropped. Anything other than dropping it would be highly unusual. A transitional package libjodycode2-dev would be possible, but there is no real benefit for a just created package. The -dev package should be named libjodycode-dev, which is a stable name.
