On Thu, 28 Nov 2013, Michael Matz wrote:
Hi,
On Thu, 28 Nov 2013, Thorsten Kukuk wrote:
No need to pollute the base buildsystem AND just EVERY installed system with kerberos and/or NIS / YP stuff if it isn't needed or wanted. What's the next proposed must-build-in dependency? CIFS(Samba) -- or maybe something else?
There is a difference:
CIFS is an external library/package, NIS is integral part of glibc and doesn't pull in other libraries.
But we don't speak here about NIS, we speak about IPv6 and RPC. NIS doesn't work at all with IPv6, the protocol is incompatible.
Sure. The last time I looked at the whole pam business is fairly long ago, so what I'll say next will have terminologies and implementation borders wrong, but it somehow must be possible (perhaps by creating a new pam module or hacks or what-have-you) to decrease the requirements of pam _for purposes of the build environment_ which doesn't have network anyway (hence NIS, but also IPv6 and RPC, are irrelevant). That (hacky) pam module or whatever it will turn out to be (perhaps a pam-mini) can be something only used in the build system, and hence can be coming with some hard-coded config that no user will ever touch. (Really, that pam is in the core cycle is the single most reason why it's so godawful difficult to keep it from growing)
It's been long ago since I looked, but the issue is that the bare
system (what is required by aaa_base) is too broad for the build
system (and also for very stripped installed systems if you consider
to populate a chroot - no booting! - that just wants to be able to
execute a shell).
That is because it requires a 'login' command.
Now we could use a different '/bin/login' providing package for
the build systems, but really aaa_base should just not require
a '/bin/login'. Instead "product meta-data" (whatever that is
in its current form) should require things that we think
need to be minimally installed.
As I said - it was really really long time ago (hackweek 1 or 2,
working on Base:install to reduce the size of the minimal
installable system). See comments we placed in
http://en.opensuse.org/Base_Project at that point in time,
especially
"Default system configuration should not be done in packages. The
rationale behind this is that a default configuration may impose
requirements on installed tools (such as pam or ldap) while this choice
should be defered to product settings (which thus need to provide a
default system configuration in some way). The exact best way to achieve
this has not been discussed yet, but the aaa_base package already does
parts of that (and would need to be made product specific)."
Richard.
--
Richard Biener