On 25/12/2022 10:20, Christoph Biedl wrote:
Thorsten Alteholz wrote...On Fri, 23 Dec 2022, Till Kamppeter wrote:Now one question: Could we implement (2) already in the current Debian release (the one which freezes in a few weeks) or do we have to stay with cups-filters 1.x there and do all the changes only after that release so that they are in place one Debian release later?the next Debian release will still have cups-filters 1.x As long as libppd is independent of cups-filters 2.x (at least I understood your first email this way), the new libppd could be already added.Um, is there a reason why we cannot have both in the upcoming Debian 12 ("bookworm")? Since Till shows an exuberant amount of enthusiasm in that matter, I'd prefer it the project could benefit from that soon.
You mean both legacy libpd and current libppd? With main binary packages being libppd0 and libppd2? Renaming legacy source package libppd to libppd0, legacy dev header binary package to libppd0-dev?
Related, looking deeper into printing in Debian: While we are too close to the bookworm release to do huge changes - it might be an idea for the next development cycle to drop lpr-based printing support completely.
I am in favor of this, too. All the LPR/LPD/LPRng and related stuff is unmaintained and probably buggy, even with security bugs, and nobody cares of this. It gets also in the way of future development as we currently see with libppd.
Not that I'm a huge fan of CUPS (although in general it works), but lprng itself is orphaned to start with, other maintainers are more or less MIA, and all the code is very old and likely full of bugs.
Yes, therefore better do away with his.
This however should be discussed with all the related package maintainers and on debian-devel as well. Nothing I can afford to spend time on right now given the bookworm freeze timeline.
OK, let us aim for complete LPD/LPR/LPRng/legacy-libppd/gpr removal for bookworm+1 ...
Till