Hi, On Sun, May 13, 2012 at 09:23:04PM +0300, Alon Bar-Lev wrote: > > Huh? You're the master of Autoconf, and I'm sure you will be able to > > produce a working PAM detection for those platforms that have it. > > Yes, and as such I tell you that automatic detection is something that > leads to package breakage. > We already discussed that in the lzo subject.
We're not talking about extra libraries that might or might not be there -
on all systems I named, PAM is part of the basic operating system, as
is "libc" or one of the zillion header files that you're currently testing
for.
> I know you are fundamentally against any change, but I think I proved
> very well that I actually know what I am doing.
Now you are the one who is opposing change. You asked what we want, and
if the plugins should not be split, how the build system should be adapted.
This is what I answered: if we want to adapt the build system for the
plugins, compile them by default, and install them. And now you're finding
reasons why this is bad.
Fine, leave it at that - there's quite obviously not much support for the
split, and since you do not want to compile & install by default, nobody
can force you to implement that.
> >> >> These plugins should be optional I don't see any value in enforcing
> >> >> them and their dependencies.
> >> >
> >> > If these plugins are useful for a large number of users, there is no
> >> > point in not installing them by default.
> >>
> >> They are not.
> >
> > Unfounded claim.
>
> I know one or two installations, and I am tracking this project more
> than 6 years.
> Come on! most of installations are plain public key without any of
> these plugins.
All our corporate servers *do* use auth-pam. Which is crucial if you
want to do things like OTP passwords that are handled by PAM - many
vendor solutions provide PAM modules, and it's quite nice to be able
to use those without any extra hoops.
For the record, these servers user FreeBSD with the default port, which
*does* install both plugins, and I find that tremendously useful.
ovsrv1$ pkg_info -W /usr/local/lib/openvpn-auth-pam.so
/usr/local/lib/openvpn-auth-pam.so was installed by package openvpn-devel-201034
> There is no need for these if you configure your server.
How do you know what I need for my servers? I *do* need them for my
server, and I'm very happy that the FreeBSD port saves me from having
to worry about the plugins manually every time I install a new OpenVPN
version.
> I simply don't understand your attitude... sorry, I simply don't.
My attitude is very simple. I'm a sysadmin and network admin, do IPv6
deployments, and regularily have to fight open source software that comes
with non-useful defaults.
Everything that creates extra work for sysadmins is bad.
Everything that brings in religion and delays software releases for
"purity" reasons, while people are waiting for features to be delivered
(and have to live with patched packages, instead of using upstream sources
directly) is bad.
Too-complex software is *bad*. Stuff that looks nice while in computer
science class, but that will bring in more complex failure modes - because
that will inevitably one day bite an overworked sysadmin, and they do not
like that.
> >> BTW: Packager of what platform are you?
> >
> > openwrt. Not that this is of any relevance.
>
> Exactly, so I think I am more experienced distro maintainer,
Which OpenVPN package are you maintaining, please remind me again?
(I am also going to win any dick size war, of course, but that's also
non relevant as I'm already married)
> please
> understand that I am taking from first hand experience, and I would
> like to help, plain positive help... I really don't understand why you
> are trying to force your opinion if you have theoretical knowledge.
*cough*
> BTW: openwrt is a good example of a platform that does not need these
> plugins right?
Indeed. So, yes, you have won. Don't enable them in the build system.
Remind me again why I am bothering?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpAGvWYQ1pJq.pgp
Description: PGP signature
