lprng-devel Mailing List for LPRng

On Fri, Jul 09, 2010 at 10:22:45PM +0200, Bernhard R. Link wrote:
> The first two patches remove krb4 and pgp support and make the third
> a bit easier.
That sounds like a good idea. I think its asking for trouble to support
such old methods.

> The third patch actually adds plugins:
I like this idea!  It means the Debian package wont require so many
libraries, by default.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

Attached a patch series I already posted 2009-08-09 which I plan
to commit if noone contradicts.

The first two patches remove krb4 and pgp support and make the third
a bit easier.


Kerberos5 exists now a very long time, so I guess kerberos4 will no
longer be needed. It's also relatively complicated by having more
than one way to be reached by code (and I do not know what is needed
to make it even compile).

using pgp for printing is also quite outdated (Does anyone even know
someone that uses pgp and not gpg?), calling external programs and
needing termporary files it might also make things more problematic
in a future clean design of plugins. So I suggest removing it.

The third patch actually adds plugins:

The advantage of dynamic loadable plugins is that all their libraries
are no longer needed when not using them and when using one only its
own libraries need to be loaded. As a side effect that allows
distributions to make packages that support all those methods without
the package needing to depend on all the libraries (a simple Suggests
instead of an Depend in Debian), so people can install lprng without
needing to install kerberos libraries and the libraries kerberos
libraries depend upon.

The current implementation is quite low-tech and not very nice but
functional:

1) It's not using libtool but just tries some compiler flags and if
they do not work falls back to do without plugins. As there is a
easy fallback (just compile in as done previously), having all the
horrors of libtool (config.guess/sub files, all those libtool scripts,
checking for fortran in configure) are avoided, as none of the features
are needed.

2) The generated plugins just use all functions and global variables
from the binary itself. This has the disadvantage that the binary has
to be compiled with -export-dynamic and the plugins cannot be compiled
when -Wl,-z,defs is in the LDFLAGS and that it looks a bit dirty.
But changing that means to rewrite most of LPRngs file handling
(which is a good idea anyway, but definitly nothing possible
middle- or even short-term).

The patch in its current form does not enable plugins by default but
only if compiled with --enable-plugins and should not change anything
when that is not given.

If enabled, it should not change behaviour (if there are no bugs
hidden), except in one case: It currently does no
longer output a list of all authentication possibilites. That could
be readded, but would most likely mean to load all authentication
plugins to get that information. perhaps just listing in which
directly to look would be a more sensible solution.

	Bernhard R. Link