[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for Removal: Unmaintained libppd in Debian



Hi,

thanks for the explanations.

First, I am really wondering that there are still users using some lpr/LPD/LPRng-type printing system, to my knowledge they are all unmaintained for decades and many years ago I have dropped their support from Foomatic. Nobody complained.

I am also wondering that as GUI/printer setup tool the totally unmaintained gpr, with unattended severe bug, is used.

My general recommendation is to switch to CUPS, the only fully maintained print environment. CUPS itself is continued to be developed by original author Michael Sweet, the integration, cups-filters, Foomatic, Common Print Dialog Backends is done by me. Also integration in GUI's is done by me, organizing appropriate Google Summer of Code projects for this. For all this I have a full-time employment at Canonical. So further maintenance is assured.

Another possibility to print, without CUPS, are the Printer Applications, emulations of driverless IPP printers. With these the user does not need to deal with PostScript. They take PDF or PWG/Apple Raster as input. The PostScript Printer Applications supports ALL PostScript printers (you can add PPD files to it if needed). So the user's client software does not need to deal with PPD files (I assume on non-CUPS spoolers, like LPD, PPD files and legacy-libppd are only used for PostScript printers). The Printer Applications are also developed by Michael Sweet and me and are also part of OpenPrinting and they use my new libraries. The user could send the jobs to a Printer Application (is there an IPP backend for LPD/LPRng/lpr?).

Modern desktop applications also produce PDF and not PostScript as print output, so best is to print with CUPS and/or Printer Applications with it.

Also practically all modern printers are (driverless) IPP printers. CUPS just prints on them, for using any print environment which does not support IPP 2.x, one would need any fallback, like PostScript or PCL, which would need a driver again and also is not available in cheaper printer models.

This all means that if a user opts for LPR/LPD/LPRng + PostScript/PPD files as printing environment, they will have a VERY special case. Extreme resource confinement, PostScript printer, no security requirements.

This can only be a very small amount of users.

In the existing user base there can also be users who are running a setup for decades, which simply works for them and so they do no modernize and rely on Debian to do at least a basic maintenance on it.

One would need to find and ask these users, to find out why tihey do not switch to CUPS.

For these few users I do not want to add such long piece as "openprinting-" to the names of my packages for the eternity, especially as this old system will fade out and all printers which worked with that, also work with CUPS and/or Printer Applications, even in a more comfortable and user-friendly way. So (3) has disqualified.

I would prefer (1), but (2) will be a good compromise to keep these legacy libppd users happy.

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? That later Debian release MUST adopt cups-filters 2.x as it will use CUPS 3.x, which has abolished PPD support and requires the use of Printer Applications for non-IPP-driverless legacy printers. Doing this switchove only after the relase also should give time that everything which needs to go through NEW will have enough time.

In Ubuntu I will switch to cups-filters 2.x with my libppd immediately (23.04 Lunar Lobster) and ditch the old libppd and gpr there (they are only in Universe), not adopting the renamed legacy libppd.

So I will package my libppd with epoch 3 and let it Breaks: and Conflicts: with equally-named packages of a lower epoch. Am I right? Do I also have to set Replaces: in this situation?

WDYT about this?

Is the API of the legacy libppd complex? Or could one find someone who could add this API to my modern libppd to keep these users happy and give them even a maintained library.

   Till

On 23/12/2022 16:52, Christoph Biedl wrote:
Hi there,

Till Kamppeter wrote...

Christoph, as you are the Debian maintainer of it, I want to ask you whether
this package has still any use or whether you could invoke the process of
requesting removal of it.

First, to avoid any misunderstanding: My motivation to take
maintainership of libppd (I'll use the name "legacy libppd" from now on
for clarity) in Debian was that package being in dire need of attention,
again. Following Debian's social contract, my interest was users of that
package are not harmed by its removal from the next release. Besides
that, I have no particular connection to it, in other words: Once I'm
convinced that package's time has passed and we can safely remove it,
I'll not hesitate to start that process.

However, I have concerns.

About users, you wrote:

So I am very confident that there is nobody using this package and if it
goes away, nobody will complain. If there is actually some other package
using this, it is probably also unmaintained for at least a decade and
nobody uses it.

Or it's feature complete and the users are happy :)

Unfortunately, I cannot agree here. According to popcon¹, we still have
users in the low three-digit range. It it was *two*-digit, I'd just say
"Let's ditch it". The given situation however requires more checking. In
my assumption the users are usually those who installed gpr ("GUI for
lpr: print files and configure printer-specific options") which depends
on legacy libppd.

Now gpr itself is in a bad state, and appearently the maintainer did not
react to a release-critical bug in months - a bug probably caused by
yours truly but still.

So in order to remove legacy libppd, we'd have to remove gpr as well,
and for both it was kind to give users an idea what to use instead -
personally, I get very upset if a package removal just says "Lots of
alternatives exist" without giving any clue how they are named and how
to migrate. (And often they are similar, nothing else.)


And there is another issue: Even if we remove both source packages from
the archives and you upload yours, some users will still expect the
legacy libppd-dev, and experience breakage. Now I don't know if there's
a grace period before re-using a source or binary package name, but I'd
say it's prudent to wait at least one Debian release cycle.


Don't get me wrong: I don't want to block your plans - I just want to
make sure the migration causes as little damage as possible.

To recap: There are two conflicting package names: The libppd source
package, and libppd-dev created from that.

So, solutions I can think of:

1. Remove legacy libppd and gpr (following your request)

    Work need boils down to create guidelines for the users, which is
    some work to do. If going that way, I could use some hands-on here.

2. Allow co-existence by renaming legacy libppd

    The conflicting binary package from (legacy) libppd is renamed to
    avoid a conflict with your version. So "libppd-dev" could become
    "libppd-legacy-dev", and keep policy 10.1 in mind². Also, gpr needs
    an according adjustment. I would take care of that as well.

    The source package name is a different story. In your position I'd
    rather prefix all these so it becomes obivous they belong together,
    so perhaps "openprinting-libppd". As an alternative, I could rename
    the source package as well, at the increased risk of confusing a few
    users.

    As a safeguard, you could consider adding some conflicts against the
    legacy packages until the 13 ("trixie") release so those are not
    installed by accident. Also, your libppd-dev should see an epoch to
    make sure its version is above mine (currently 2:0.10-8).

    Biggest concert for me: An updated legacy src:libppd would have to go
    through NEW, nodoby knows how long that will take.

3. Allow co-existence by naming your package differently

    We can avoid all the hazzle if ship your packages with a
    non-conflicting name (like "openprinting-libppd-dev"). And we'd also
    avoid user want my package but get yours.

    That's no work for me :)  But it feels bad since it does a change in
    the new place - a place that will stay longer than the old one.

My preference is 2-1-3, and I'm open for other suggestions.


Aside, I guess you want to have that resolved in bookworm already? Then
let's not waste time, freeze is getting close.

Regards,

     Christoph

¹ https://qa.debian.org/popcon.php?package=libppd
² Assuming you already have a packaging, mind to share the file list of
   that one?


Reply to: