[lsb-discuss] Possible to get rid of /usr/bin/sendmail requirement in LSB 4.1?

Till Kamppeter till.kamppeter at gmail.com
Sat Feb 20 13:15:34 PST 2010


Till Kamppeter wrote:
> One problem which I have with the LSB is the requirement of 
> /usr/bin/sendmail. This pulls in a mail server system with daemon on 
> many systems, taking resources, opening a possible security hole, asking 
> question to non-tech users during the MTA installation, ... This can 
> easily happen only when a printer driver from OpenPrinting gets 
> installed and this can make users complain, up to users refusing LSB 
> packages.
> 
> See http://bugs.linuxbase.org/show_bug.cgi?id=2407
> 
> Now I want to know whether there happened already investigations 
> concerning the removal of /usr/bin/sendmail from the LSB 4.1 
> requirements, as Mats Wichmann talked about in his comment on 
> above-mentioned bug report.
> 
> I also want to know whether one can perhaps surround this requirement by 
>  letting the LSB-packaged software not require "lsb" but a sub-package 
> like for example "lsb-printing". Are these sub-package names 
> standardized? We will also have to structure the content of the 
> sub-packages appropriately, as for now the "lsb-printing" of the "lsb" 
> package in Ubuntu requires "lsb-core" which in turn requires 
> /usr/bin/sendmail. perhaps one can change these dependencies somehow so 
> that lsb-printing does not pull sendmail.

What about solving this problem? From the LSB side I think the best way 
is to split the LSB into several sub specs (not more than 10), for 
example lsb-common, lsb-server, lsb-desktop, lsb-printing, ...? Then I 
would let the printer drivers depend on lsb-print and not on lsb, then 
only lsb-common (lsb-print depends on it) and lsb-printing would be 
pulled. lsb-server (which requires sendmail) is not needed then. A 
server app from an ISV which must be capable to send out e-mail 
notifications but not able to print would depend on lsb-server. As 
legacy backward compatibility "lsb" would depend on all "lsb-..." 
modules. This would also not need completely new test suites and 
interface docs but only some reorganization and discussion what goes 
into which module.

I think this would be the best solution for the problem.

    Till

See also: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/141641



More information about the lsb-discuss mailing list