[lsb-discuss] Packaging

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Oct 25 20:39:04 PDT 2006


>> Can I make an LSB compliant PAM module?  PAM isn't specified, so I
guess
>> I need to bundle PAM.  I could probably get away with not doing this
>> because ABI compatibility is generally easier for plugins.  Now, I
need
>> to use my bundled version of PAM.  That means manipulating a bunch of
>> files that are not in my /opt/vendor/foobar directory.  If I
understand
>> correctly, the LSB answer is that it is now the sysadmin's job to
make
>> it work, and LSB cannot permit the package to automatically
manipulate
>> the system.
>
>Actually, PAM is specified in the LSB.  What isn't specified is how to
>manipulate the various files in /etc/pam.d, and the reality is that
>the layout of those files are different across different
>distributions.  Worse yet, depending on what's in the file, it's hard
>to know exactly in what order to insert a particular pam module in the
>middle of a file like /etc/pam.d/login. 

Turns out the module interface is not specified either, so you can't
make a compliant module, but you can write a program that /calls/
PAM in a compliant way.

(yes, I understand PAM was just an example anyway. it's an
interesting example because it points at an issue that isn't
cleanly handled by the current LSB/FHS filesystem namespace protection
rules or installer rules - that is, plugin architectures that
require some files, either plugins or configuration files that
say where to find the plugins, in a very specific place, rather
than where FHS says you can install 3rd-party files. but that's
kind of a different topic...)




More information about the lsb-discuss mailing list