Re: Request for Removal: Unmaintained libppd in Debian
On 27/12/2022 09:33, Christoph Biedl wrote:
Till Kamppeter wrote...
[ migrating legacy-libppd applications to libppd2 ]
Unfortunately, it is not that simple but also not over-complicated. The
developers had ripped the code for PPD handling from libcups, but they did
not like Michael Sweet's original API. They replaced the API by a glib-based
one. To keep gpr happy one would need to create wrapper functions with the
new API to the outside and calling the original functions in libppd. One
would use the code of the legacy libppd, remove each API-function's (there
are ~20 API functions) inner workings and replace them by calls of functions
in the current libppd. The resulting code could be put together all into one
pp/ppd-legacy.c file.
I do not actually know how much work this would be and whether it is
worthwhile for the actual number of users of gpr or ppdfilt to do this work.
Errrm. I mean, if you got a lot of time to kill, or are thrilled to do
this, or at least could earn an academic degree from such work ... but
perhaps let's rather forget the idea?
Unfortunately I do not have a lot of time to kill ...
[ ppdfilt ]
and I was wondering where your toolset will provide an replacement as
well. While I could continue to ship legacy libppd with only this binary
package, it might be a good opportunity to drop this one and therefore
complete libppd as well. It seems ppdfilt is used by gpr and
printfilters-ppd ("filters from the GNUlpr printing system"), another
thing from old times. Both are maintained by A Mennucc1, we should take
them into the loop at some time.
As I found out in the meantime (the dusty corners): printfilters-ppd has
dropped out of testing almost six years ago because of mpage removal
and some other issues. And nobody bothered to resolve the situation -
which I admit is not a trivial task to do.
In other words, no need to take care of printfilters-ppd.
Good to know ...
Probably most users had already switched to Foomatic, partially also
guided by their distro, already before it adopted CUPS ...
Probably your (2) could perhaps be the way to go?
Yes. Current mood, besides kicking lpr* completely (see my other mail):
Long-term goal is actually kicking lpr*, going (2) is only interim ...
Go indeed (2). It's a step not too big. There is however still a little
obstacle: If you'll introduce your libppd-dev later, none of its file
names may collide with my libppd-legacy-dev. That will be your problem,
not mine - still now is a good time to prevent this from happening.
That's why I asked for your preliminary libppd packaging: Do we share
file names, especially in /usr/include/ and /usr/share/man/?
My current step to do is preparing the libppd package. As a preview we
can simply look at what "make install" actually installs:
----------
$ ls -R
.:
usr
./usr:
include lib share
./usr/include:
ppd
./usr/include/ppd:
ppdc.h ppd-filter.h ppd.h
./usr/lib:
libppd.a libppd.la libppd.so libppd.so.2 libppd.so.2.0.0 pkgconfig
./usr/lib/pkgconfig:
libppd.pc
./usr/share:
doc ppdc
./usr/share/doc:
libppd
./usr/share/doc/libppd:
ABOUT-NLS CHANGES-1.x.md CONTRIBUTING.md DEVELOPING.md NOTICE
AUTHORS CHANGES.md COPYING INSTALL README.md
./usr/share/ppdc:
epson.h font.defs hp.h label.h media.defs raster.defs
$
----------
This gives for libppd2:
/usr/lib/libppd.so.2.0.0
/usr/lib/libppd.so.2
for libppd-dev:
/usr/include/ppd/ppd.h
/usr/include/ppd/ppd-filter.h
/usr/include/ppd/ppdc.h
/usr/lib/libppd.so
/usr/lib/libppd.a
/usr/lib/pkgconfig/libppd.pc
for libppd2-common:
/usr/share/ppdc/*
For the -dev packages the headers (*.h) do not clash as the legacy
libppd puts the files directly into /usr/lib and the current libppd uses
/usr/lib/ppd/. Only clashes would be /usr/lib/libppd.so and
/usr/lib/libppd.a (are these files really needed?), so we need to mark a
comflict and rename thelegacy libppd-dev package lippd-legacy-dev or
libppd0-dev.
The legacy libppd has no ppdc stuff and the current libppd no ppdfilt,
so there are no further conflicts.
Till
Reply to: