[Luca Capello 2011-01-07] > Hi there! Hi. Sorry for my late reply.
> I thought about that as well, but why would you prefer that (a single > package for a 7k module...) to preseeding, as you suggested in your > first post? Preseeding only work when the package is installed. And I would like to be able to enable pam_mkhomedir by just installing the set of packages needed for the task/profile I want to set up on the machine, also after it is already installed. I would rather not having to edit config files after installation, as this tend to give upgrade problems. And i can not really safely uninstall libpam-runtime to preseed its new value by installing it again after the preseed value is loaded into debconf. Thus I end up suggesting to split the pam module into separate packages, to allow everyone to pick the PAM setup we want by just installing the modules we want to enable. > ===== > luca@gismo:~$ debconf-show libpam-runtime | grep profiles > debconf: DbDriver "passwords" warning: could not open \ > /var/cache/debconf/passwords.dat: Permission denied > libpam-runtime/no_profiles_chosen: > * libpam-runtime/profiles: unix, ldap, smbpasswd-migrate, mkhomedir > luca@gismo:~$ > ===== I believe these preseeding values do not really work when installing 1500 packages in one tasksel run, where some of them are PAM modules, because not all of them will be installed and configured when pam-auth-update uses the preseed value, thus the machine might end up with the wrong setup, depending on installation order for the packages. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
