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 <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org