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?
[ 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.
> Probably your (2) could perhaps be the way to go?
Yes. Current mood, besides kicking lpr* completely (see my other mail):
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/?
Christoph
Attachment:
signature.asc
Description: PGP signature