Hi Till, On 10.10.24 20:11, Till Kamppeter wrote:
the new generation of cups-filters (2.x), split into libcupsfilters, libppd, cups-filters, and cups-browsed, each of version 2.x, is not part of CUPS 3.x. They are designed to work with BOTH CUPS 2.x and CUPS 3.x. They detect the presence of the CUPS version (2.x or 3.x) in the "./configure" step and then build appropriately.
I am afraid this is the problem. CUPSv3 is not a drop in replacement for CUPSv2. In your scenario nobody can prepare for the transition until the switch in libcupsfilters is done. So after this switch is done on an arbitrary date, nobody who is using unstable/testing or the Ubuntu equivalent is able to print. As I am sure the CUPSv3 software is not without bugs in the beginning (who shall find those bugs when nobody can install packages to test), nobody knows how long printing will not work. I don't think this is acceptable for Debian, so I separate CUPSv2 and CUPSv3 as long as possible, introduce new packages for the CUPSv3 family and keep old packages for the CUPSv2 family. Of course both can not be used together, so they need to conflict and at the moment this is libcupsfilters/cups-filters. In addition to this I wonder whether it is possible to assign bugs and CVEs to the correct version when only using libcupsfilters. From my point of view it will be a great mess when some bugs in libcupsfilters need to be closed and others need to be opened just because a libcupsfilters/CUPSv2 is replaced by a libcupsfilters/CUPSv3, but the underlying software version did not change.
If you have any problems with the transition in Debian, please check the Ubuntu packages.
Yes, Ubuntu users are already used to complications :-). Thorsten
