Bug#1027424: transition: libppd
On 2022-12-31 10:29:48 +0100, Paul Gevers wrote: > Control: tag -1 moreinfo > > Hi Christoph, > > On 31-12-2022 10:06, Christoph Biedl wrote: > > possible this is not a regular transition, but in exchange I guess it > > should be pretty smooth and simple ... > > Inside the Debian archive maybe, but ... > > > So src:libppd has been renamed to src:libppd-legacy, and has entered > > experimental yesterday. While doing so, I've fixed a longstanding > > mismatch in the soname version, hence the new number libppd-legacy*1*. We have libppd0 with an incorrect SONAME already in oldoldstable (maybe also oldoldoldstable). We are not doing transition for such cases. That's gonna stick until we can properly remove libppd.so.1 from the archive. > I'm wondering what this means for users of the library that don't have > packages in the Debian archive. If some downstream (including the non > publicly published ones) (build) depend on the old library, they suddenly > get weird failures, right? That's why we are not doing those kind of transitions. Technically, the new libppd can start using libppd.so.2, but this sounds less than optimal. Can't the new one be named something else if it's not a successor to the old libppd? Cheers -- Sebastian Ramacher
Bug#1027424: transition: libppd
Paul Gevers wrote... > On 31-12-2022 10:06, Christoph Biedl wrote: > > > So src:libppd has been renamed to src:libppd-legacy, and has entered > > experimental yesterday. While doing so, I've fixed a longstanding > > mismatch in the soname version, hence the new number libppd-legacy*1*. > > I'm wondering what this means for users of the library that don't have > packages in the Debian archive. If some downstream (including the non > publicly published ones) (build) depend on the old library, they suddenly > get weird failures, right? Correct. Install-dependencies will fail for a missing libppd.so.1.0.1, just like after any other transition (Till's libppd will use a different soversion). Build-dependencies will fail to build as the new libppd is not a drop-in replacement. Till did some investigation in that direction, result boils down to "Providing a compatability layer was possible but is some work", while odds are low anyone will benefit from this, see below. So, in the case of a failing re-build, users will need to learn about the reason and how to deal with it. I've asked Till to embed an according pointer in the packages' descriptions (debian/control) so they'll have a clue. However, I would be fairly surprised if that ever happens. This is very old software and it is mostly unmaintained - last (legacy) libppd upstream release was in 2005. Therefore I assume any third-party package switched to something different in the meantime. I am not aware of any, and a little research didn't show anything in that direction. Looking for "libppd" usually just points to the new version, provided by OpenPrinting. Our alternative would have been to make the new libppd somehow fit around the old one, stupid work, and with constant risk people will pick the wrong one - something I consider way more likely to happen than failing builds of some rather hypothetical third-party packages based on legacy libppd. > At the extreme bare minimum, this needs documentation in the release notes, > but I wonder if we consider this enough. Release notes will never hurt, thanks for reminding me about those. And in the particular situation I'm confident this is enough. If you can think of more safety nets I could provide, let me know. Regards, Christoph signature.asc Description: PGP signature
Processed: Re: Bug#1027424: transition: libppd
Processing control commands: > tag -1 moreinfo Bug #1027424 [release.debian.org] transition: libppd Added tag(s) moreinfo. -- 1027424: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027424 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1027424: transition: libppd
Control: tag -1 moreinfo Hi Christoph, On 31-12-2022 10:06, Christoph Biedl wrote: possible this is not a regular transition, but in exchange I guess it should be pretty smooth and simple ... Inside the Debian archive maybe, but ... So src:libppd has been renamed to src:libppd-legacy, and has entered experimental yesterday. While doing so, I've fixed a longstanding mismatch in the soname version, hence the new number libppd-legacy*1*. I'm wondering what this means for users of the library that don't have packages in the Debian archive. If some downstream (including the non publicly published ones) (build) depend on the old library, they suddenly get weird failures, right? At the extreme bare minimum, this needs documentation in the release notes, but I wonder if we consider this enough. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1027424: transition: libppd
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: lib...@packages.debian.org, Till Kamppeter Control: affects -1 + src:libppd Greetings, possible this is not a regular transition, but in exchange I guess it should be pretty smooth and simple ... So some background: There are major changes coming in the area of printing using CUPS, driven by Till Kamppeter (Cc'd), and among other things this will introduce a library "libppd" to interact with PPD (PostScript Printer Description) files. That one however will clash with an existing libppd, maintained by yours truly, and after some discussion with Till we figured the sane way was to move that old library out of the way, name-wise. So src:libppd has been renamed to src:libppd-legacy, and has entered experimental yesterday. While doing so, I've fixed a longstanding mismatch in the soname version, hence the new number libppd-legacy*1*. Now about the formal transition procedure: There is exactly one reverse build-dependency, src:gpr, I've already filed #1027408 for the required changes. Taking care of this is on my list. That should be all - if you need more information, just let me know. Kind regards, Christoph Ben file: title = "libppd"; is_affected = .depends ~ "libppd0" | .depends ~ "libppd-legacy1"; is_good = .depends ~ "libppd-legacy1"; is_bad = .depends ~ "libppd0"; signature.asc Description: PGP signature
